Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 27 October, 2022
In den letzten Wochen wurden die Schichten des Netzwerks stark abgetragen und dafür gesorgt, dass das, was darunter liegt, stabil ist. Diese Woche werden wir darüber sprechen, wie wir hoffen, diese Arbeit zu integrieren und was dies für uns in Zukunft bedeuten sollte.
Allgemeiner Fortschritt
Mostafa beschäftigt sich intensiv mit Konsensmechanismen und wie wir sie auf einige Funktionen von Safe Network anwenden können, einschließlich der Mitgliedschaftsprobleme, auf die wir weiter unten eingehen.
@davidrusu und @dirvine sind auch in diesen Dingen kopfüber, arbeiten sich durch die Grenzfälle und stellen sicher, dass sie mit unseren geplanten Mechanismen behoben werden.
@bochaco arbeitet zusammen mit @joshuef und @qi_ma noch an Fehlern bei der Messaging-Implementierung und Konnektivität. Der funktionierende Zweig, den wir vor main gepflegt haben, sieht gut aus.
Dann gibt es noch die Frage, was genau passiert, wenn eine GET-Anforderung gestellt wird. Was muss signiert werden und welche Mindestinformationen müssen mit dem Chunk gesendet werden, damit der Erwachsene identifiziert, überwacht und bestraft werden kann, wenn er fehlschlägt? @ansleme und @oetyng schauen sich das jetzt hauptsächlich an.
Und an der Testfront passt @chriso den selbst gehosteten Runner für GitHub Actions CI/CD neu an, um den von uns verwendeten Fork zu vereinfachen.
Nächste Schritte zur Stabilität
In letzter Zeit haben wir hart daran gearbeitet, die unteren Schichten des Netzwerks zu stabilisieren (wie wir letzte Woche gesehen haben). Wir haben die Verbindungsverwaltung vereinfacht und mehrere Ebenen von „Retry“-Code aus den Ebenen „sn_client“ und „sn_node“ entfernt, die seltene Fehler verschleierten (die im Laufe eines länger laufenden Testnetzes und vieler Tests häufiger wurden). Daran haben wir in den Verbindungsmanagement- und Node-Storage-Layern sowie in der Mitgliedschaft gearbeitet.
Da wir uns auf diese Instabilität konzentriert haben, sind wir dazu übergegangen, ein einfacheres CI-Setup zu verwenden. Dies hat Tests, die nacheinander arbeiten, aber viel konsistenter arbeiten, außer für ein paar Probleme, die auf „Haupt“ auftauchen. Dies ist jedoch mit einer viel einfacheren Einrichtung der Verbindungsverwaltung und einem Großteil der „Wiederholungsschicht“ entfernt.
Wir haben dies noch nicht durch die Testnet-Wringer gebracht, da wir immer noch versuchen, die verbleibenden Probleme zu beheben: Mitgliedschaftsverzögerungen … (dafür wird eine Lösung getestet); gelegentlich langsame API-Tests – die anscheinend damit zusammenhängen, dass die Mitgliedschaft nicht mehr synchron ist; und sehr gelegentliche DBC-Testfehler.
Wir hoffen, unseren Arbeitszweig sehr bald mit main zusammenführen zu können. Sobald wir das haben, werden wir versuchen, diese Stabilitätsgewinne mit einigen weiteren CI-Verbesserungen zu sichern.
Weitere Tests
Wir werden Tests hinzufügen, um alle Pfade für Erwachsene und ältere Menschen zu überprüfen (Ermöglichung von Split-Tests, Datenausgleich bei Abwanderung usw.) und jeden einzelnen Erwachsenen überprüfen, der Daten speichern sollte, Daten speichert. Dies sollte es uns schließlich ermöglichen, zu einem einfacheren Happy-Path-Setup für Client-Kommunikation überzugehen (dh Kommunikation mit nur einem Ältesten … Warten auf eine ACK vor dem Versuch der Überprüfung), was die Netzwerklast weiter reduzieren wird.
Sobald wir das eingerichtet haben, werden wir versuchen, alle PRs durch einen angepassten CI-Workflow zu zwingen. Wir werden die Tests so straffen, dass sie zunächst nur auf Linux-Rechnern laufen (da diese am schnellsten sind). Die vollständige Suite läuft nur, wenn die PR überprüft wurde (über BORS, unseren CI-Roboter).
Dies sollte hoffentlich die Feedback-Schleife zu unseren PRs beschleunigen, wobei BORS das CI-Fleisch bereitstellt und auf allen Plattformen testet, sobald die PR überprüft wurde.
Und obwohl das allein nicht eine Million Meilen von dem entfernt ist, was wir jetzt haben … CI sollte stabiler und nützlicher sein (BORS verwaltet ausstehende PRs und Rebases automatisch; wie wir hier vielleicht schon einmal erwähnt haben) … Und … Wir werden dann dem BORS-Flow ein vollständiges Droplet-Testnetz hinzufügen, was bedeutet, dass main nur Code enthält, der jeden Test, den wir haben, auf jeder Plattform und unter allen Netzwerkbedingungen bestanden hat!
Und mit main, zuverlässig, getestet und veröffentlichbar, werden wir viel besser in der Lage sein, an Verbesserungen, Benchmarks und neuen Funktionen zu arbeiten, ohne an der Stabilitätsfront auszurutschen.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufügen.
Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!