Dies ist eine Übersetzung des Original-Artikel geschrieben von 
Das Hive-Netzwerk auf Equilibrium aktualisiert.
Die wichtigste Errungenschaft war das erfolgreiche Upgrade des Hive Network zum Hardfork 25 (das Equilibrium-Release), und es wurde viel Zeit damit verbracht, das Upgrade zu überwachen und Hive-Applikationen bei Bedarf während des Übergangs zu unterstützen.
Das Equilibrium-Upgrade hatte einen unerwarteten Nebeneffekt: Die Änderung der Kurationsregeln führte dazu, dass Votes, die nach dem Hardfork abgegeben wurden, in Bezug auf die Kurationsgewichtung viel stärker waren als Votes, die vor dem Hardfork abgegeben wurden, was bedeutete, dass Votes, die in den Tagen vor der Hardfork abgegeben wurden, im Allgemeinen nicht viel an Kurationsbelohnungen erhielten. Dies war ein vorübergehender Effekt, der jetzt behoben ist, da alle Beiträge, über die jetzt aktiv abgestimmt wird, nach dem Hardfork erstellt wurden, aber hoffentlich haben wir bei der nächsten Iteration des Testnets genug Traffic, dass wir in der Lage sein werden, solche Probleme rechtzeitig zu erkennen.
Hived Work (Blockchain Node Software)
Verbesserungen an den Testtools und den Tests, die zur Überprüfung der Hived-Funktionalität verwendet werden:
https://gitlab.syncad.com/hive/hive/-/merge_requests/272
Neue Flag -exit-before-sync zur Befehlszeilenschnittstelle von hived hinzugefügt (nützlich für das Dumpen eines Snapshots ohne anschließende Synchronisierung, siehe https://gitlab.syncad.com/hive/hive/-/issues/66 für weitere Details, warum diese Option hinzugefügt wurde):
https://gitlab.syncad.com/hive/hive/-/merge_requests/232
https://gitlab.syncad.com/hive/hive/-/merge_requests/273
Wir haben den zuvor gemeldeten Fehler behoben, bei dem ein Hived nach dem Laden eines Snapshots neu gestartet werden muss:
https://gitlab.syncad.com/hive/hive/-/merge_requests/274
Wir haben die Leistung unseres neuen "Blockchain-Konverter"-Werkzeugs zur schnellen Erstellung von Testnets, die das Hauptnet widerspiegeln, analysiert und einige Codes im Zusammenhang mit Nonces als möglichen Engpass identifiziert.
Hivemind (Middleware für soziale Medien)
Wir haben einen neuen Programmierer zu unserem hivemind-Team hinzugefügt. Er wird zunächst an Tests und kleineren Fehlerbehebungen arbeiten, um die Codebasis kennenzulernen. Sein erster Merge Request ist hier: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/518
Wir haben Code zur Überprüfung der Konsistenz der Tabelle hive_blocks hinzugefügt (dies ist Teil des zuvor erwähnten Plans, um einen robusten Betrieb für den Fall sicherzustellen, dass der Postgres-Prozess von hivemind plötzlich herunterfährt oder ein Rollback fehlschlägt): https://gitlab.syncad.com/hive/hivemind/-/merge_requests/516
Wir arbeiten weiter an der Verbesserung der Leistung der Funktion update_rshares unmittelbar nach dem Massive Sync einer Hivemind-Instanz. Wir versuchen zwei verschiedene Alternativen, um die Gesamtleistung zu verbessern: 1) Änderung des Massive Sync, so dass es rshares für bezahlte Beiträge on-the-fly aktualisiert, wodurch die Arbeit von update_rshares auf die Aktualisierung von rshares für unbezahlte Beiträge reduziert wird (dieser Ansatz erfordert die Einführung einer neuen hived virtual_operation) und 2) Hinzufügen eines Index (zumindest vorübergehend direkt nach dem Massive Sync), um update_rshares zu beschleunigen. Beide Ansätze befinden sich derzeit in der Testphase.
Wir haben auch die Suche nach dem Grund wieder aufgenommen, warum einige Hivemind-Knoten mehr Speicher verbrauchen als andere. Es wurde angedeutet, dass es mit Unterschieden in der Python oder Python-Bibliotheksinstallation auf den verschiedenen Systemen zusammenhängen könnte, was ich zu diesem Zeitpunkt zu glauben geneigt bin, da wir auf keinem unserer Produktionsnodes, auf denen die neueste offizielle Hivemind-Version läuft, mehr unerwarteten Speicherverbrauch sehen. Wenn wir also nicht in der Lage sind, dieses Problem in unseren kommenden Tests zu replizieren, werden wir dieses Thema wahrscheinlich bald fallen lassen, nachdem wir unsere diagnostischen Änderungen eingebunden haben, die die Quellen der Speichernutzung besser identifizieren.
Hive Application Framework (HAF)
Unser Hauptentwickler für diese Arbeit ist derzeit im Urlaub.
Ich hatte gehofft, dass wir in der Zwischenzeit noch am psql_serializer-Plugin arbeiten können (das Daten von hived nach hivemind unter dem HAF-System einspeist), aber der damit beauftragte Dev war mit anderen Problemen beschäftigt (z. B. mit der Behebung des Snapshot-Problems). Ein neuer Entwickler wurde diese Woche mit der Arbeit an psql_serializer beauftragt (der zuvor beauftragte geht für zwei Wochen in Urlaub).
Condenser und Wallet (Open-Source-Codebasis für https://hive.blog und andere ähnliche Frontends)
Wir haben eine Reihe von Verbesserungen, die von der Community beigesteuert wurden, überprüft und in den Condenser und dessen Wallet integriert.
Von
: https://gitlab.syncad.com/hive/wallet/-/merge_requests/102
Von
: https://gitlab.syncad.com/hive/condenser/-/merge_requests/269
Was steht als nächstes an?
Mehrere unserer Hive-Entwickler sind entweder im Urlaub oder gehen in der kommenden Woche in Urlaub (sie hatten ihren Urlaub verschoben, um für den Hardfork und mögliche Probleme, die danach auftreten könnten, verfügbar zu sein). Wir werden also in den nächsten zwei Wochen nur 8 BlockTrades-Entwickler haben, die an Hive arbeiten, und unser Fortschritt wird sich während dieser Zeit zwangsläufig etwas verlangsamen.
Nachdem alle unsere Hive-Entwickler aus dem Urlaub zurück sind, werden wir uns ein paar Wochen Zeit nehmen, um zu planen, welche Arbeiten wir für den nächsten Hardfork (HF26) einplanen. Ich habe einige vorläufige Ideen für Verbesserungen, an denen unser Team arbeiten wird, aber wir werden eine vollständige Liste der vorgeschlagenen Änderungen erstellen und dann beginnen, Prioritäten zu setzen, was wir in die Roadmap für HF26 einbauen wollen. Mein Plan zu diesem Zeitpunkt ist es, an unserem bestehenden Zeitplan "Hive-Protokoll alle sechs Monate aktualisieren" festzuhalten, wenn möglich.
Außerdem sind unsere Roadmaps, wie bei früheren Hardforks, nicht in Stein gemeißelt, so dass wir auch nach der Veröffentlichung der ersten Roadmap weitere Änderungsvorschläge in Betracht ziehen können, vorausgesetzt, die Änderungen sind nicht zu groß.
Beachtet, dass der oben beschriebene Prozess nicht bedeutet, dass wir keine klaren Entwicklungsziele vor der Fertigstellung der HF26-Roadmap haben. Zum einen werden wir Leistungsverbesserungen an hived vornehmen, die keinen tatsächlichen Hardfork erfordern, und diese Änderungen werden im Allgemeinen veröffentlicht, sobald sie fertiggestellt sind.
Noch wichtiger ist, dass sich zu diesem Zeitpunkt unsere Aufgaben mit höchster Priorität um die Erstellung des HAF-Frameworks und HAF-basierter Anwendungen drehen, und das sind alles Layer-2-Arbeiten, die keine Änderungen am Hive-Protokoll erfordern, die einen Hardfork notwendig machen würden. Mit anderen Worten, wir können HAF und die zugehörigen Anwendungen für die Entwicklergemeinschaft freigeben, sobald sie fertig sind, ohne die Arbeits- und Zeitplanungsprobleme, die mit dem Upgrade der Nodes im Rahmen eines Hardfork verbunden sind.