Dies ist eine Übersetzung des Original-Artikel geschrieben von @blocktrades zur Arbeit an der Hive Software: https://peakd.com/hive-139531/@blocktrades/15th-update-of-2021-on-blocktrades-work-on-hive-software (Veröffentlicht: Donnerstag 10 Juni 2021)
Die Arbeit des BlockTrades-Teams hat sich in der letzten Zeit etwas verlangsamt, da ein Großteil unserer Belegschaft über die Feiertage an Fronleichnam frei hatte und in den letzten beiden Tagen ein von der Firma gesponserter Erholungsausflug in die Berge stattfand (und heute erholen sich wahrscheinlich viele Leute davon). Trotzdem haben wir an mehreren Fronten Fortschritte gemacht:
Hived Work (Blockchain Node Software)
Wir gehen davon aus, dass wir morgen den Release Candidate 4 kennzeichnen werden (diese Version läuft bereits seit über einer Woche im Testnet, wurde aber noch nicht offiziell gekennzeichnet, da einige false-positive Tests fehlgeschlagen sind, die noch beseitigt werden müssen).
Unter der Annahme, dass bis Montag keine Probleme für diesen Release Candidate gemeldet werden (hoffentlich wird das Testnet an diesem Wochenende viel getestet), werden wir den Code in den Master-Zweig einfließen lassen und eine offizielle Version von hived (aka v1.25.0) markieren.
Wir werden auch eine letzte Überprüfung der Build- und Installationsdokumente durchführen und als nächstes werden wir die Börsen kontaktieren und sie über den erwarteten Hardfork am 30. Juni informieren, damit sie ihre Wallets vorzeitig aktualisieren können.
Hivemind (Anwendungen im 2. Layer + Middleware für soziale Medien)
Wir haben einen Fehler in der neuesten Version von hivemind gefunden und arbeiten gerade an einer Korrektur. Dieses Problem manifestierte sich am sichtbarsten als Reputationsberechnungsfehler für zwei Hive-Konten, obwohl wir glauben, dass es möglicherweise zu anderen Fehlern führen könnte.
Die Ursache des Problems liegt darin, dass wir ein Code-Refactoring durchgeführt haben, um einen Teil des Codes, der während der Massensynchronisierung verwendet wird, für die Verarbeitung von Blöcken während der Live-Synchronisierung zu verwenden. Diese Version des Codes verarbeitete Blöcke in drei separaten Transaktionen, und wenn eine dieser Transaktionen fehlschlug, blieb die von den anderen beiden Transaktionen geleistete Arbeit bestehen, was zu Inkonsistenzen in den Daten auf der fehlerhaften Node führen konnte.
Die wahrscheinliche Lösung besteht darin, wieder eine einzige Transaktion für die Blockverarbeitung während der Live-Synchronisation zu verwenden, und wir werden wahrscheinlich in der Lage sein, die Lösung Ende nächster Woche zu implementieren.
Fix für Regression der Hivemind-Synchronisationszeit
Wir haben auch eine Regression in der Hivemind-Synchronisationszeit getestet/behoben, bei der die update_posts_rshares Abfrage manchmal unangemessener Weise einen sequenziellen Scan in die Abfrageplanung einbezog, was dazu führte, dass die anfängliche Synchronisationszeit für eine Datenbank mit 53 Mio. Blöcken um etwa 12 Stunden verlängert wurde.
Unser erster Test des Fixes zeigt eine dramatische Verbesserung (dauert jetzt nur noch 15 Minuten), aber wir müssen noch mehr testen, um sicherzustellen, dass die Verbesserung unter allen Bedingungen anhält. Der anfängliche Performance-Test für den Fix wurde mit einer Datenbank-Dump-Datei durchgeführt, während die 12-Stunden-Messung mit einer Datenbank durchgeführt wurde, die aus einem vollständigen Sync erstellt wurde, so dass wir die Performance noch unter einem vollständigen Hivemind-Sync (der mehrere Tage dauert) testen müssen, um einen genauen Vergleich anzustellen.
Ich betrachte den aktuellen Fix als eine Art Workaround, da wir im Wesentlichen den Plan des Abfrageplaners basierend auf seinen internen Schätzungen überschreiben und ihn zwingen, einen sequentiellen Scan zu vermeiden. Später werden wir versuchen, den Planer dazu zu bringen, besser zu schätzen, indem wir seine Sammlung von Statistiken und die Gewichtung der Kosten verbessern, weil wir wissen, dass ähnliche schlechte Schätzungen Postgres 13 dazu veranlassten, unangemessene "Just-in-Time"-Optimierungen auf dieselbe Abfrage anzuwenden. Es ist also denkbar, dass wir, wenn wir in der Lage sind, den Schätzungsprozess des Planers zu korrigieren, eine optimalere Leistung erhalten, wenn sich die statistische "Form" der Daten im Laufe der Zeit ändert.
Hive Application Framework (HAF ist der neue "offizielle" Name für den modularen Hivemind)
Wenn es keinen Volksaufstand gibt, denke ich, dass ich mich auf einen offiziellen Namen für das Projekt geeinigt habe, das wir unter dem "Codenamen" des modularen Hivemind entwickelt haben: Hive Application Framework aka HAF.
Ich denke, dass Hive Application Framework die eigentliche Funktionalität viel besser beschreibt und es ist deutlicher von der hivemind Social Media Anwendung zu unterscheiden. Außerdem eignet es sich besser für Werbe-Taglines wie: "HAF - Ihre Blockchain-App ist schon fertig!"
Erstes Release von HAF voraussichtlich irgendwann im Juli
In der letzten Woche haben wir den Code und die Dokumentation für HAF überarbeitet und verbessert, insbesondere den Code, der die automatische Handhabung von Forks ermöglicht. Wir hatten am Montag eine Telefonkonferenz, um den Stand der Arbeit zu besprechen und weitere Verbesserungen zu besprechen, und basierend auf meinen positiven Gefühlen aus diesem Treffen, schätze ich, dass wir in der Lage sein werden, irgendwann im Juli eine offizielle Veröffentlichung von HAF zu machen.
Laufende Arbeiten am HAF
Die jüngste Änderung besteht darin, den Wechsel zwischen einer Hive-Anwendung, die nur auf irreversible Blöcke angewiesen ist, und einer, die auch reversible Blöcke verarbeitet, zu vereinfachen.
In diesem Zusammenhang werden wir auch versuchen, die Optimierung der Blockverarbeitung zu automatisieren, wenn ein Prozess, der mit reversiblen Blöcken arbeitet, gerade irreversible Blöcke verarbeitet (ursprünglich war geplant, dass die Anwendung signalisieren muss, wenn sie vorhat, in einer optimierten Weise mit irreversiblen Blöcken zu arbeiten).
Wir werden auch eine Skeleton-Code-Vorlage erstellen, um zu veranschaulichen, wie eine typische Hive-App das HAF-Framework verwenden würde, und später eine vollwertige Beispielanwendung.
Aktualisierungen am sql_serializer-Plugin für Änderungen am hive_fork_plugin
Bevor wir einen vollständigen Test des Frameworks durchführen können, müssen wir auch einige notwendige Verbesserungen am sql_serializer-Plugin für Hive vornehmen, das Daten in die Postgres-Datenbank schreibt. Insbesondere muss dieser Code aktualisiert werden, um API-Änderungen zu unterstützen, die an der Hive-Fork-Manager-Erweiterung vorgenommen wurden (dies ist der SQL-Code, der die Verfolgung reversibler Blöcke und die Rückgängigmachung der Tabellenänderungen einer Anwendung verwaltet, wenn ein Fork auftritt).
Die oben genannten Arbeiten werden morgen beginnen und ich hoffe, dass wir in der Lage sein werden, einen vollständigen Test von hived + hivemind sync bis Ende nächster Woche durchzuführen.
Aufruf an App-Entwickler für Feedback zum HAF
An diesem Punkt leidet sie zwar noch unter einigen Tippfehlern, die ich in Kürze korrigieren werde, aber ich denke, dass die Architekturdokumentation für HAF gut genug ist, dass ich Feedback von allen App-Entwicklern mit einer existierenden oder geplanten App haben möchte, insbesondere von allen Anwendungen, die eine eigene Datenbank und eine eigene API benötigen.
Bitte überprüft die Architekturdokumentation und helft uns, die bestmögliche Ausgangsbasis für Hive-Apps zu schaffen. Hier ist ein Link zur aktuellsten Version des Dokuments:
https://gitlab.syncad.com/hive/psql_tools/-/blob/mi_hive_fork_plugin2/src/hive_fork/Readme.md
Congratulations @louis88! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next payout target is 36000 HP.
The unit is Hive Power equivalent because your rewards can be split into HP and HBD
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOP