[Blocktrades] Update zu Blocktrades Arbeit und den HF24 Ergebnissen.

^{Dies ist eine Übersetzung des Originalbeitrags geschrieben von @blocktrades:
https://peakd.com/hive-139531/@blocktrades/update-on-blocktrades-work-and-the-results-of-hf24}

Ich veröffentliche diesen Beitrag etwas früher, da ich damit rechne, dass ich am Montag ziemlich beschäftigt sein werde. Bevor ich auf meine normale Berichterstattung über die detaillierten Programmierungsfragen, an denen das BlockTrades-Team in der vergangenen Woche gearbeitet hat, und unsere Pläne für die kommende Woche eingehe, möchte ich zunächst einen kurzen Überblick über den Hardfork-Prozess der vergangenen Woche geben, da dieser unseren Arbeitsablauf in der vergangenen Woche bestimmt hat.

Überprüfung von Hardfork 24 (und einem "ungeplanten" Hardfork davor)

Am Tag des Hardfork 24 (14. Oktober) nahmen die Entwickler der Anwendungen noch Hardfork 24-bezogene Änderungen vor und meldeten API-Probleme, die sie mit hivemind gefunden hatten, während das BlockTrades-Team an der Behebung dieser Fehler arbeitete, während sie gemeldet wurden (ich werde die Fehlerbehebungen später in diesem Beitrag erörtern). In der Zwischenzeit standen die Top 20 Witness bereit und warteten auf ein "Entwarnungssignal", dass genügend Anwendungen stabil waren, so dass wir den Hardfork sicher ausführen konnten, indem wir ihre API-Nodes auf den Hardfork-24-Code aktualisieren konnten (im hivemind-Node-Repository entweder als v1.24.2 oder v1.24.3 gekennzeichnet).

Mehrere der 20 führenden Witness hatten ihren Code bereits auf den Hardfork-24-Code aktualisiert, aber dies wurde von mir und anderen Entwicklern als in Ordnung erachtet, da der HF24-Code eine Super-Mehrheit der führenden 20 Witness erfordert, um auf ihn umzuschalten und das neue HF24-Protokoll auszulösen, das er enthält. Dies ermöglichte es einigen der 20 wichtigsten Witness, nicht warten zu müssen, bis die Integration von Apps/Hivemind ein akzeptables Niveau erreicht hatte, bevor wir das Hardfork-Protokoll auslösen konnten.

Leider führte dies zu einem unerwarteten Nebeneffekt: Der HF24-Code enthielt eine Protokolländerung, die vor Hardfork 24 nicht ordnungsgemäß vor der Ausführung geschützt war. Das bedeutet, dass eine HF24-Node einen Block erzeugen konnte, der von HF23-Knoten nicht akzeptiert wurde. Wir hatten diesen Fehler noch nie zuvor ausgelöst gesehen, da er nur dann ein Problem verursachen konnte, wenn ein HF24-Knoten einen Block produzierte, und auch dann nur unter besonderen Umständen.

Es gab einige Male vor dem Hardfork-Datum, wo wir eine HF24-Node als produzierenden Node betrieben haben, aber in der Vergangenheit war eine solche Node in der Minderheit, so dass das Schlimmste, was passieren konnte, wenn dieser Fehler ausgelöst wurde, war, dass die HF24-Node vorübergehend einen Fork durchführte und dann wieder in den Konsens mit der Kette zurückfiel, wenn der von ihm erzeugte Block von den HF23-Nodes nicht akzeptiert wurde.

Aber beim Hardfork-Datum hatten wir zwar keine Super-Mehrheit der Top 20 Nodes, auf denen HF24 lief, aber wir hatten eine Mehrheit, die HF24 lief. Und eine Mehrheit reicht aus, um zu bestimmen, wie Blockchain Forks gelöst werden. Wenn also einer der HF24-Nodes einen Block produzierte, der von HF23-Nodes abgelehnt, aber von HF24-Nodes akzeptiert wurde, behielt die Fork-Auflösungslogik die HF24-Nodes auf einem separaten ungeplanten HardFork von den HF23-Nodes (wodurch die Blockchain effektiv in zwei Forks aufgeteilt wurde).

Die Top 20 Witness erkannten schnell, was vor sich ging, so dass sie sich entschlossen, den Hardfork auszuführen, indem sie die verbleibenden HF23-Nodes auf HF24 aufrüsteten, so dass alle Knoten wieder bei dem Mehrheit-Fork waren. Dies erforderte auch, dass alle Betreiber von API-Nodes ihre API-Nodes auf den HardFork24 upgraden mussten, und alle Hive-Anwendungen wechselten auf ihre HF24-Versionen, um diese API-Nodes nutzen zu können.

Da der Hardfork 24 aufgrund der Blockchain-Spaltung etwas früher ausgeführt wurde, als wir es uns gewünscht hätten, hatten wir zum Zeitpunkt des Hardfork 24 noch immer nicht alle Fehler und Leistungsprobleme in den hivemind- und Hive-Anwendungen behoben. Dies führte in den letzten Tagen zu verschiedenen Pannen und Verzögerungen für die Benutzer von Anwendungen. Aber die Hive-Entwickler haben hart daran gearbeitet, die Probleme so schnell wie möglich zu lösen und die Dinge sehen bereits viel besser aus. Ich erwarte, dass die verbleibenden Probleme recht bald gelöst werden.

Eine Sache für die Zukunft: Ich möchte nach Möglichkeiten suchen, Probleme wie die Spaltung der Blockchain zu erkennen, bevor sie auftreten. Eine Möglichkeit wäre die Einrichtung einer speziellen sekundären Witness-Node, der den neuen Code ausführt und Blöcke als Top-20-Zeuge signiert, wobei die von ihm produzierten Blöcke jedoch nur an eine isolierte alte Code-Node gesendet werden, der sich melden würde, wenn er keinen der Blöcke annehmen könnte, die er von der neuen Node empfangen hat. Wir können die Möglichkeit, dass dieses Problem in der Praxis auftritt, auch dadurch verringern, dass wir die meisten der Top 20 Witness sehr zeitnah aufrüsten lassen, aber das kann uns nur so weit bringen: Die ideale Lösung wäre eine bessere Testmethode, um solche Probleme aufzudecken, und ich denke, eine gewisse Variation meines obigen Vorschlags sollte funktionieren.

Hived Arbeit (Blockchain-Node-Software)

Wir nahmen mehrere Änderungen an den API-Antworten vor, die von hived zurückgesendet wurden, meist als Reaktion auf Berichte von App-Entwicklern:
https://gitlab.syncad.com/hive/hive/-/merge_requests/125
https://gitlab.syncad.com/hive/hive/-/merge_requests/126
https://gitlab.syncad.com/hive/hive/-/merge_requests/133

Wir führten auch eine allgemeine Bereinigung der Docker, Skripte und Konfigurationsdateien für Hived durch:
https://gitlab.syncad.com/hive/hive/-/merge_requests/130

Wir haben auch ein Problem mit der Cli-Wallet behoben: Diese benutzte nach dem HardFork immer noch die alte Blockchain-ID, so dass sie keine ordnungsgemäßen Transaktionen generieren konnte. Anscheinend gab es nur sehr wenige oder gar keine Tests, die zuvor zum Testen der Cli-Wallet geschrieben worden waren.
https://gitlab.syncad.com/hive/hive/-/merge_requests/128

Der Cli-Wallet-Fix war für den Austausch notwendig, deshalb haben wir eine neue Version v1.24.4 getaggt, die diese Änderung (und die anderen oben genannten Korrekturen) enthält. Beachten Sie, dass keine der oben genannten Änderungen von Konsen-Witness benötigt wird, weshalb Witness in erster Linie immer noch mit 1.24.2 arbeiten. Diese Änderungen werden nur für API-Nodes und Exchanges benötigt.

Wir haben gestern eine vollständige Neuaufzeichnung (replay) gestartet, um alle obigen Änderungen zu überprüfen (dies dauert etwa 18 Stunden). Wir erwarten keine Probleme, da die Änderungen als Nicht-Konsensus-Änderungen konzipiert wurden, nur Änderungen an der API, aber besser auf Nummer sicher gehen.

Hivemind (2. Ebene Social Media Microservice)

Die meiste Zeit haben wir noch mit hivemind verbracht, aber wir haben sehr gute Fortschritte gemacht.

Unsere Verbesserungen an hivemind lassen sich in zwei Kategorien einteilen: Fehlerbehebungen (falsche oder fehlende Daten in API-Antworten) und langsame Abfragen, die zu inakzeptablen Antwortzeiten führen. Unsere Fehlerbehebungen werden in der Regel als Reaktion auf Berichte von Anwendungsentwicklern durchgeführt, aber langsame Anfragen werden in der Regel durch Beobachtung der Leistung der von unserem API-Nodes verwendeten Postgres-Server mit dem Tool pghero erkannt. Wir haben festgestellt, dass pghero sehr praktisch ist, um herauszufinden, welche SQL-Abfragen die meiste Zeit in Anspruch nehmen (es fungiert als Profiler). Es ist auch nützlich, um doppelte und unnötige Indizes zu finden, die die Leistung beeinträchtigen können.

Hier ist eine Liste von Verbesserungen und Fehlerbehebungen, die wir an hivemind vorgenommen haben:

Dezentralisierte Listenänderungen wurden nach Aktualisierungen ebenfalls in den Entwicklungszweig zusammengeführt (der Code war seit diesen Änderungen stark divergiert, so dass er eine ordentliche Menge an manuellem Zusammenführen und Testen erforderlich waren):
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/275

Hivemind Status

Mit den neuesten Optimierungen (die letzte große war der Merge-Request 310 vom Samstag) scheint hivemind recht gut zu funktionieren, aber wir müssen noch einige weitere Optimierungen vornehmen und wir müssen auch die Reputationsaktualisierung wieder aktivieren (dies wurde vorübergehend deaktiviert, weil weitere Optimierungen erforderlich waren, um inakzeptable Verlangsamungen der Synchronisierung zu vermeiden, die eine übermäßige Belastung der hivemind-Nodes beim Empfang von Datenverkehr aus der realen Welt verursachten).

Wir haben eine optimierte Version des Reputations-Synchronisations-Algorithmus auf einem lokalen Entwicklungssystem, aber wir werden ihn auf einem unserer experimentellen API-Server mit API-Traffic aus der realen Welt weiter testen, bevor wir ihn zum Teil des offiziellen Builds machen.

Wir führen derzeit eine vollständige hivemind-Synchronisierung durch (dies war im Allgemeinen ein viertägiger Prozess), um zu sehen, ob es irgendwelche Probleme gibt, da wir diesen Prozess in der letzten Woche übersprungen und inkrementelle Upgrades an unserer bestehenden hivemind-Datenbank durchgeführt haben, um neue Änderungen schnell zu testen.

Experimentieren mit der optimalen API-Node Konfiguration

Eine weitere Sache, die wir diese Woche gemacht haben, ist das Experimentieren mit der Konfiguration unserer API-Nodes für optimale Leistung. Ich habe einige der Informationen, die wir im API-Node-Owner-Kanal entdeckt haben, weitergegeben, aber ich werde später hier einen vollständigen Bericht über unsere Ergebnisse erstellen, sobald wir diese Arbeit abgeschlossen haben.

Condenser (Open-Source-Code für hive.blog)

Wir haben einige weitere Änderungen an hive.blog und dessen Wallet vorgenommen, die mit Änderungen in hardfork 24 zusammenhängen. (Hauptsächlich an der Wallet, da wir bereits mehrere Aktualisierungen am Condenser selbst vorgenommen haben). Insbesondere die Entfernung von Verwendungen der get_state-Funktion, die zugunsten effizienterer API-Aufrufe veraltet ist.
https://gitlab.syncad.com/hive/wallet/-/merge_requests/38
https://gitlab.syncad.com/hive/wallet/-/merge_requests/39
https://gitlab.syncad.com/hive/wallet/-/merge_requests/40
https://gitlab.syncad.com/hive/wallet/-/merge_requests/42
https://gitlab.syncad.com/hive/wallet/-/merge_requests/43
https://gitlab.syncad.com/hive/wallet/-/merge_requests/45

https://gitlab.syncad.com/hive/condenser/-/merge_requests/118
https://gitlab.syncad.com/hive/condenser/-/merge_requests/121
https://gitlab.syncad.com/hive/condenser/-/merge_requests/119

Eine Korrektur, die wir bald einsetzen müssen, ist eine Änderung, damit der Condenser den Zustand des Vote-Buttons nach dem Vote eines Benutzers korrekt aktualisiert:
https://gitlab.syncad.com/hive/condenser/-/merge_requests/129

Was steht als nächstes in dieser Woche an?

Wir müssen noch ein paar weitere Optimierungen an hivemind vornehmen, und ich gehe davon aus, dass wir noch ein paar Fehlerberichte erhalten werden. Außerdem müssen wir noch den endgültigen Code zur Berechnung der Reputation einsetzen. Ich gehe jedoch davon aus, dass sich diese Arbeit in den nächsten Tagen verlangsamen wird, obwohl der vollständige Hive-Sync-Test wahrscheinlich nicht vor Ende der Woche abgeschlossen sein wird (Wir haben heute bereits eine Verlangsamung bei der vollständigen Synchronisierung mit den letzten Änderungen beobachtet, die einer Analyse bedarf).

Wir werden auch den Condenser und die Wallet testen und nach Korrekturen und Optimierungen suchen, die wir vornehmen können.

^{Dies ist eine Übersetzung des Originalbeitrags geschrieben von @blocktrades:
https://peakd.com/hive-139531/@blocktrades/update-on-blocktrades-work-and-the-results-of-hf24}

Sort:

Trending

[-]

condeas (67) 4 years ago

Nun habe ich es endlich richtig verstanden, ist halt besser wenn es jemand ins Deutsche übersetzt, der es auch kann :-)

$0.02

louis88 (78)Witness louis.witness 4 years ago

Danke. Ja, ich dachte mir halt, da es bei einigen Nutzern doch immer ein paar Fragezeichen auf dem Kopf sind und mich dann mit Blocktrades ausgetauscht, ob es für ihn in Ordnung ist, das ich es Übersetze. Somit kann auch die deutschsprachige Community es besser verstehen, was hinter den Kulissen so passier.

$0.00

stayoutoftherz (78) 4 years ago

Danke fürs Update. Leider gibt es immer noch ein paar kleinere Nachwehen bei peakd, bei der Anzeige der Anzahl der Kommentare zum Beispiel, und die Notifications werden spürbar langsamer angezeigt.

mima2606 (72) 3 years ago

Danke Dir für die gute Übersetzung und den damit verbundenen Mehrwert.

Liebe Grüße Michael

!invest_vote
!jeenger

investinthefutur (70) 3 years ago

@mima2606 denkt du hast ein Vote durch @investinthefutur verdient!
@mima2606 thinks you have earned a vote of @investinthefutur !

jeenger (68) 3 years ago

Your contribution was curated manually by @mima2606
Keep up the good work!

Kannst du mir oder vielleicht auch jemand anders der das liest mir ein bisschen mehr zu Hiver Mind sagt. Mir ist schon klar dass das wohl eine Datenbank sein muss aber welche Verbesserungen bringt diese mit oder was ändert sich dadurch?