Dienste und Betrieb

Das Repository enthält zwei unabhängige Prozesse: einen Keeper, der erlaubnisfreie Aufrufe sendet, und ein Ereignisrelais, das Veröffentlichungen vorbereiten kann. Eine lokale Konfiguration beweist nicht, dass ein Dienst durchgehend läuft.

Der Keeper

Der Keeper prüft das Netzwerk und die Hook-/Lens-Verknüpfungen und fragt dann den Snapshot ab. Im dokumentierten Ablauf bevorzugt er den Rebalance, wenn dieser zulässig ist, andernfalls die Platzierung von Mitteln und anschließend den isolierten Burn, wenn die anderen Vorgänge nicht verfügbar sind.

Er simuliert vor dem Senden und verarbeitet höchstens eine Aktion pro Block. Erwartete Ablehnungen wegen fehlender Zulässigkeit sind normale Ergebnisse; RPC-Fehler und unerwartete Simulationsergebnisse müssen als bearbeitbare Fehler gemeldet werden.

Mit einem Dry-Run beginnen

Im Verzeichnis services/, nach Installation und lokaler Konfiguration gemäß README:

DRY_RUN=true pnpm keeper:once

Dieser Modus erlaubt es, Netzwerk, Deployment, aufgelöste Adressen, Zulässigkeit und Schätzungen zu prüfen, ohne eine Transaktion einzureichen.

Das Betriebswallet sollte ausschließlich für Gas bestimmt sein. Es muss weder Deployer noch Team oder Guardian sein. Die Parameter für maximales Gas und Mindestprämie begrenzen die Ausführung; sie garantieren keinen Gewinn.

Transaktionsjournal und Wiederaufnahme

Der Keeper trennt die Zustände nach Blockchain, Hook, Wallet und Dry-Run-/Live-Modus. Er verwendet eine lokale Prozesssperre und ein dauerhaftes Journal für Absicht, Nonce und Hash.

Nach einem Timeout oder Neustart nimmt er zuerst die Verfolgung der bestehenden Transaktion wieder auf, bevor er eine neue Aktion vorbereitet. Eine Absicht ohne Hash ist mehrdeutig: Vergleichen Sie die ausstehenden und bestätigten Nonces des Wallets, bevor Sie das Journal ändern.

Eine .lock-Datei darf erst entfernt werden, nachdem bestätigt wurde, dass ihr früherer Prozess nicht mehr läuft. Diese Sperren sind lokal; sie koordinieren nicht mehrere Rechner. Verwenden Sie für jede Instanz ein geeignetes Wallet und einen geeigneten Zustand.

Weiterentwicklung der Module

Der aktuelle Lens wird aus der Registry aufgelöst. Bewahren Sie während des gesamten Vorgangs die Identität des Kerns und den Revisionskontext.

Die Version mit mehreren Walls erfordert eine Aktualisierung von ABI, Vorschauen, Ablehnungsgründen und Ereignissen. Ein auf eine einzelne Wall ausgelegter Keeper darf ohne entsprechende Abnahme nicht als für diese neue Version validiert dargestellt werden.

Das Ereignisrelais

services/floor-bot liest die Ereignisse, bereitet einen Text vor und speichert einen Cursor sowie die Deduplizierungsschlüssel transactionHash:logIndex.

Dry-Run- und Veröffentlichungsmodus haben getrennte Zustände. Die Cursor enthalten den Blockchain- und Hook-Kontext; auf den vom Dienst vorgesehenen Netzwerken werden finalisierte Blöcke verwendet. Eine Reorganisation oder ein inkonsistenter Checkpoint muss vor der Wiederaufnahme abgeglichen werden.

Das Relais speichert vor der Veröffentlichung einen pendingPost dauerhaft. Akzeptiert der externe Dienst die Nachricht, während der Prozess vor dem Speichern des Erfolgs stoppt, muss vor einem erneuten Versuch geprüft werden, ob die Nachricht bereits existiert: Eine lokale Datenbank und ein soziales Netzwerk können nicht gemeinsam committen.

Das GitBook führt keine Veröffentlichungen aus. Der tatsächliche Einsatz des Relais unterliegt einer getrennten betrieblichen Konfiguration und Autorisierung.

Die Wortwahl an feste Walls anpassen

Das frühere Relais meldete FloorRaised-Ereignisse. Mit der aktuellen Regel kann eine Finanzierung eine Wall zu einem niedrigeren Preis als die letzte Finanzierung erstellen, während bestehende Niveaus erhalten bleiben.

Das Relais muss daher die betroffene Wall, ihr Niveau und die hinzugefügten Mittel nennen, ohne allein aus dem Ereignisnamen einen globalen Anstieg abzuleiten. Frühere Meldungen wie „der Floor steigt immer“ beschreiben diese Regel nicht.

Hilfreiche Betriebskontrollen

Verfolgen Sie RPC-Fehler, Konfigurationsabweichungen, ausstehende Belege, Simulationsfehler, das Gasguthaben des Keepers und das Alter des zuletzt verarbeiteten Blocks. Bewahren Sie Wiederanlaufprotokolle und Versionsidentitäten ohne private Signaturdaten auf.

Eine Überwachung, die Prozesse neu startet, ersetzt nicht die Klärung einer mehrdeutigen Nonce oder einer Registry-Änderung.

Quellen: services/keeper/README.md, services/floor-bot/README.md, services/keeper/src/index.ts und services/shared.