Der Proof-of-Stake (PoS) -Mechanismus von Sui integriert Epochen und Validator-Sets, um Netzwerksicherheit und Konsens zu gewährleisten, was sich erheblich von EVM-Ketten unterscheidet. Hier finden Sie eine ausführliche Erklärung, die auf Ihre Entwicklungsziele zugeschnitten ist:

Epochen in Sui

Sui arbeitet in diskreten Zeiträumen, sogenannten Epochen, die jeweils etwa 24 Stunden dauern (konfigurierbar, standardmäßig 864.000 Slots mit ~150 ms pro Slot). Epochs verwalten Änderungen am Validator-Set und Konsensparameter:

• Struktur: Jede Epoche beginnt mit der Festlegung der Parameter einer Systemtransaktion (z. B. Schwellenwerte für Einsätze, Belohnungen) und endet mit einem Checkpoint, der die Statusänderungen abschließt.
• Übergang: Validatoren schlagen eine neue Epoche mithilfe eines Systemwechselaufrufs vor, wofür eine 2f+1-Zustimmung erforderlich ist (wobei f die maximale Anzahl fehlerhafter Validatoren ist). Dadurch wird eine Neukonfiguration ausgelöst, bei der das Netzwerk kurz pausiert.
• Zweck: Epochen ermöglichen dynamische Aktualisierungen von Validator-Sets, Neudelegierung von Stakes und Parameteranpassungen, ohne dass die Kette unterbrochen werden muss.

Validator-Sets und POs

Sui verwendet ein delegiertes PoS-Modell, bei dem Validatoren auf der Grundlage von abgesetzten SUI-Tokens ausgewählt werden:

• Wahl: Die Validatoren müssen einen Mindestbetrag setzen (z. B. 30 SUI, einstellbar), um eine Delegation der Nutzer anzuziehen. Die besten N Validatoren (z. B. 100) nach Gesamteinsatz bilden das aktive Set.
• Konsensus: Sui verwendet ein Byzantine Fault Tolerant (BFT) -Protokoll (Narwhal/Bullshark) für gemeinsam genutzte Objekte, wodurch sichergestellt wird, dass 2F+1 ehrliche Validatoren von insgesamt 3F+1 sind. Für einfache Transaktionen verwendet es eine parallele Verarbeitung ohne vollständigen Konsens.
• Prämien und Kürzungen: Validatoren erhalten Prämien aus Transaktionsgebühren und der Umverteilung von Speicherfonds, proportional zum Einsatz. Fehlverhalten (z. B. doppeltes Unterschreiben) führt zu Kürzungen, obwohl die Einzelheiten von der Unternehmensleitung festgelegt werden.
• Rotation: Am Ende der Epoche lösen Einsatzänderungen ein neues Validator-Set aus. Inaktive Validatoren werden beendet und neue kommen auf der Grundlage der Einsatz-Rangliste hinzu.

Dies steht im Gegensatz zu den statischen Validator-Sets von EVM in PoS-Ketten wie Ethereum, wo Änderungen über Hard-Forks oder Upgrades erfolgen.

Architektonische Konzepte

• System State Object: Verfolgt Epochendaten (z. B. Startzeit, Validator-Set) und wird durch Systembewegungen aktualisiert.
• Parallelität: Das Objektmodell von Sui ermöglicht es, dass sich nicht überschneidende Transaktionen den Konsens umgehen, wodurch epochenbezogene Engpässe im Vergleich zur sequentiellen Ausführung von EVM reduziert werden.
• Reconfig Time: Eine kurze Pause (Sekunden) bei Epochenübergängen sorgt für Zustandskonsistenz — ein einzigartiger Kompromiss im Hinblick auf Flexibilität.

Codestruktur verschieben

Systemverschiebungen verwalten Epochenübergänge, aber Entwickler können mit Epochendaten interagieren. Beispiel:

bewegen Modul my_module: :epoch_tracker { benutze sui: :epoch_time: :epochTime; benutze sui: :tx_context: :txContext;

Die öffentliche Struktur EpochData hat den Schlüssel, store { id: UID, aktuelle_Epoche: u64, }

öffentlicher Eintrag fun update_epoch (Daten: &mut epochData, epoche: u64, ctx: &mut txContext) { data.current_epoch = Epoche; //Zusätzliche Logik basierend auf Epoche }

öffentlicher Eintrag fun create_epoch_tracker (ctx: &mut txContext) { lass data = epochData { id: Objekt: :neu (ctx), aktuelle_epoche: epoche_zeit: :aktuelle_epoche (ctx), }; transfer: :transfer (Daten, tx_context: :sender (ctx)); } }

• Wichtige Punkte: Benutze epoch_time: :current_epoch, um auf die aktuelle Epoche zuzugreifen. Systemverschiebungen (z. B. sui_system: :request_add_validator) sind auf Governance beschränkt.
• Sicherheit: Validiert die Epochendaten, um Manipulationen während der Neukonfiguration zu verhindern.

CLI-Nutzung

Verwalten Sie Validator-Interaktionen und Epochendaten über Sui CLI:

• Epoche prüfen: bash Sui-Client get-epoch-info

• Ausgabe: Aktuelle Epoche, Startzeit, Validator-Set.

• Stake SUI (als Delegator): bash sui Kundenanteil --Betrag 100 --Validator --Gasbudget 1000000

• Achten Sie auf: Ungenügendes Guthaben oder ungültige Validator-Adresse.

• Erweiterung des Validators anfordern (nur für Governance-Zwecke, im Localnet simuliert): bash sui client call --package --module sui_system --function request_add_validator --args --gas-budget 1000000

• Hinweis: Erfordert die Systempaket-ID und die Governance-Rolle.

• Localnet-Setup: bash sui-test-validator --with-faucet

• Simulieren Sie Epochenübergänge, indem Sie die Konfiguration anpassen (z. B. die Epochendauer verkürzen).

Bewährte Verfahren und Sicherheitsprinzipien

1. Epoch-Aware Logic: Entwerfen Sie Verträge, um Neukonfigurationspausen zu verarbeiten (z. B. Transaktionen erneut versuchen).
2. Stake-Monitoring: Verwenden Sie CLI oder SDK, um die Validator-Stakes zu verfolgen und so die Delegierung an zuverlässige Knoten sicherzustellen.
3. Testen: Simulieren Sie Epochenübergänge im Localnet mit sui-test-validator --epoch-duration-ms 10000, um das Verhalten zu testen.

• Häufiger Fehler: Die Transaktion ist während der Neukonfiguration abgelaufen — erhöhen Sie den Timeout oder versuchen Sie es erneut.

4. Sicherheit: Vermeiden Sie es, sich ohne Validierung auf epochenspezifische Daten zu verlassen, da Neukonfigurationen den Status ändern können.
5. Realistische Bedingungen: Testen Sie mit unterschiedlichen Einsatzverteilungen im Testnetz, um Änderungen am Validator-Set nachzuahmen.

Unterschiede zu EVM und Development Impact

• Dynamische Validatoren: EVM PoS (z. B. Ethereum) repariert Validatoren bis zu Upgrades, während die epochenbasierte Rotation von Sui die Anpassungsfähigkeit unterstützt, ideal für DeFi-Liquiditätspools, die häufig angepasst werden müssen.
• Parallelität: Die Parallelität von Sui auf Objektebene reduziert im Gegensatz zu den blockbasierten Limits von EVM den Epochen-Overhead, was NFT-Mining- oder Wallet-Batch-Operationen zugute kommt.
• Entwicklung: Die Einschränkungen bei der Systemverlagerung von Move erfordern — im Gegensatz zum Einsatz von EVM mit offenem Vertrag — eine Interaktion mit der Unternehmensleitung, was eine sorgfältige Planung der Funktionen im Zusammenhang mit Validatoren erfordert.

Häufige Fehler und Problembehebungen

• Reconfig ignorieren: Es wird davon ausgegangen, dass der Dauerbetrieb bei Übergängen fehlschlägt. Fix: Implementieren Sie die Wiederholungslogik.
• Ungültiger Einsatz: Ein Einsatz unter der Mindestanzahl löst Fehler aus. Fix: Überprüfen Sie get-epoch-info auf Schwellenwerte.
• Netzwerkkonflikt: Die Verwendung der Mainnet-CLI im Testnet schlägt fehl. Fix: Am Zielnetzwerk ausrichten (z. B. sui client switch --env testnet).

Dies gilt für Smart Contracts (epochenbasierte Logik), NFTs (validatorabhängiges Minting), Wallets (Stake Tracking) und DeFi (dynamische Liquiditätspools). Testen Sie ausgiebig auf localnet/testnet, um die Robustheit über Epochengrenzen hinweg sicherzustellen.

Sui arbeitet an einem zeitbasierten System namens Epochen. Jede Epoche dauert standardmäßig etwa 24 Stunden, dies kann jedoch geändert werden. Du kannst dir Epochen wie Spielrunden vorstellen: Zu Beginn legt das System die Regeln, die Prüferliste und die Belohnungsparameter fest; am Ende legt es den Status fest und bereitet dich auf die nächste Runde vor. Beim Übergang von einer Epoche zur nächsten gibt es eine kurze Pause, die als Reconfig Time bezeichnet wird. Sie dauert einige Sekunden. In dieser Pause stoppt das Netzwerk kurz, um sich sicher zu aktualisieren.

Lassen Sie uns nun über Validatoren sprechen. Sui verwendet ein delegiertes Proof-of-Stake (PoS) -System. Validatoren müssen eine Mindestmenge an SUI einsetzen (sagen wir 30 Token) und mehr Delegationen von Benutzern anziehen, um es in die Top-N-Liste zu schaffen, die definiert, wer für diese Epoche in das aktive Validator-Set aufgenommen werden darf. Wenn dein Validator es nicht an die Spitze schafft, wird er beim nächsten Epochenübergang rausgeschmissen. Die Höhe der Einsätze und die Delegierung bestimmen also tatsächlich automatisch die Rotation der Validatoren — im Gegensatz zu Ethereum, wo die Validator-Sets so ziemlich fest sind, es sei denn, es gibt ein Netzwerk-Upgrade oder irgendeine Art von Governance-Vorschlag.

In Sui dreht sich das Proof-of-Stake (PoS) -System um sogenannte Epochen — stellen Sie sich diese wie Zeitfenster vor, in denen ein Validator-Set für den Betrieb des Netzwerks gesperrt bleibt. Jede Epoche dauert standardmäßig etwa 24 Stunden, ist aber konfigurierbar. Wenn eine Epoche beginnt, legt das System Regeln wie Einsatzschwellen fest und wer im Validator-Set ist. Wenn sie endet, schließt das System den Status sauber ab und bereitet sich auf den nächsten vor.

Jetzt wird es interessant: Während des Wechsels zwischen den Epochen pausiert das Netzwerk für ein paar Sekunden. Diese Pause wird als Neukonfigurationszeit bezeichnet und gibt dem System Platz, um Validatoren sicher zu rotieren oder interne Parameter zu ändern. Ihre App muss dies wissen, da Transaktionen, die in diesem kurzen Zeitfenster gesendet werden, fehlschlagen oder ablaufen können.

Die Auswahl des Validators ist dynamisch. Wenn Sie einen Validator betreiben, müssen Sie einige SUI einsetzen und andere dazu bringen, sie an Sie zu delegieren. Das Netzwerk wählt automatisch die besten Validatoren nach Gesamteinsatz aus und bildet in jeder Epoche das aktive Set. Wenn jemand mehr Einsatz als Sie erhält, werden Sie möglicherweise in der nächsten Runde rausgeschmissen. Delegierte können ihren Einsatz auch in jeder Epoche verschieben, sodass alles fließend ist. Im Gegensatz zu Ethereum, bei dem Änderungen an den Validatoren Protokoll-Upgrades erfordern, kümmert sich Sui einfach jeden Tag darum.

Consensus funktioniert auch anders. Sui verwendet Narwhal und Bullshark für Transaktionen mit gemeinsamen Objekten, die koordiniert werden müssen. Handelt es sich in Ihrer App jedoch um eigene Objekte — wie persönliche Wallets —, wird der vollständige Konsens übersprungen und die Dinge werden parallel verarbeitet. Das ist ein entscheidender Faktor, denn es bedeutet, dass deine Transaktionen nicht hinter denen warten, die nichts miteinander zu tun haben, wie das bei Ethereum der Fall ist.

Im Move-Code kannst du die aktuelle Epoche mit epoch_time: :current_epoch (ctx) abrufen. Wenn Sie beispielsweise ein Modul erstellen, das auf Epochenänderungen reagiert, können Sie Ihr eigenes Objekt erstellen, um Epochenwerte zu speichern und zu aktualisieren. Hier ist eine grundlegende Skizze, wie das aussieht:

module my_module::epoch_tracker {
    use sui::epoch_time;
    use sui::tx_context::{Self, TxContext};
    use sui::object;
    use sui::transfer;

    struct EpochData has key, store {
        id: UID,
        current_epoch: u64,
    }

    public entry fun create(ctx: &mut TxContext) {
        let epoch = epoch_time::current_epoch(ctx);
        let data = EpochData { id: object::new(ctx), current_epoch: epoch };
        transfer::transfer(data, tx_context::sender(ctx));
    }

    public entry fun update(data: &mut EpochData, epoch: u64, ctx: &mut TxContext) {
        data.current_epoch = epoch;
    }
}

Im Sui Network sind Epochen und Validator-Sets zentrale Bestandteile seines delegierten Proof-of-Stake (DPoS) -Konsensmodells. Eine Epoche in Sui ist ein Zeitfenster mit fester Länge (z. B. 24 Stunden), in dem ein bestimmtes Validator-Set für die Verarbeitung von Transaktionen und die Erstellung von Blöcken verantwortlich ist. Jede Epoche beginnt mit einer Rekonfigurationsphase, in der sich das Validator-Set auf der Grundlage von Staking-Eingaben aus der vorherigen Epoche ändern kann.

1. Epochen und Rotation des Validators

Jede Epoche hat ein einzigartiges Validator-Set, das durch den Gesamteinsatz bestimmt wird, der an jeden Validator delegiert wird.

Delegatoren setzen ihre SUI-Tokens an Validatoren ab und beeinflussen so, wer in der nächsten Epoche der aktiven Gruppe beitritt.

Am Ende einer Epoche pausiert das Netzwerk kurz, um es neu zu konfigurieren, den Checkpoint der Epoche fertigzustellen und zum nächsten Validator-Set überzugehen.

2. Struktur des Validator-Sets

Das Validator-Set wird in einem Move-Objekt gespeichert, das vom Systemmodul 0x3: :sui_system verwaltet wird.

Jeder Validator hat Metadaten, einschließlich seines öffentlichen Schlüssels, seines Einsatzes, seiner Provision und seiner Netzwerkadresse.

Struct-Validator { Metadaten: ValidatorMetadata, Stimmrecht: u64, Gaspreis: u64, Provisionssatz: u64, ... }

3 Einsatz und Delegation

Staker interagieren per CLI oder SDK mit dem Sui-Systemmodul, um Stakes zu delegieren:

Sui Kundenbeteiligung --amount 1000000000 --validator <VALIDATOR_ADDRESS>

Eingespielte Token sind gesperrt und beeinflussen den Gesamteinsatz des Validators für die nächste Epoche.

Die Prämien werden innerhalb der Epochengrenzen verteilt und können über die Methode withdraw_rewards beansprucht werden.

4. Interaktion bewegen

Die Funktion sui_system: :request_epoch_change wird automatisch aufgerufen, um Validatoren zu rotieren.

Intelligente Verträge kontrollieren Epochen nicht direkt, können aber mithilfe des Moduls sui_system auf Validator-Informationen für die Governance- oder Staking-Logik zugreifen.

5. CLI/SDK-Nutzung

Um die aktuelle Epoche und die Validatoren abzufragen:

Aufruf des Sui-Clients --package 0x3 --module sui_system --function get_current_epoch sui-Clientaufruf --package 0x3 --module sui_system --function get_validator_set

Aus dem SDK:

const epochInfo = warte auf provider.getLatestsUISystemState (); console.log (epochInfo.epoch, epochInfo.ActiveValidators);

6. Möglichkeit der On-Chain-Verwaltung

Die Struktur von Sui ermöglicht eine fortschrittliche Staking-Logik oder epochenorientierte Verträge, z. B. die Übertragung oder Neugewichtung von Logiken, die epochenbedingt sind.

7. Häufige Fallstricke

Die Verwendung veralteter Validatoradressen kann dazu führen, dass das Staking fehlschlägt.

Wenn Sie zu kurz vor dem Ende einer Epoche delegieren, können die Auswirkungen bis zum nächsten Zyklus verschoben werden.

Verträge können nicht direkt auf die Zeit zugreifen, sondern müssen die Systemuhr- oder Epochendaten verwenden.

8. Testen und bewährte Verfahren

Im Localnet können Sie Epochenübergänge simulieren, indem Sie Folgendes aufrufen:

sui genesis --epoch-duration-ms 10000

Überwachen Sie Rekonfigurationen mit dem Ereignis EpochChangeEvent.

9. Sicherheit

Stellen Sie sicher, dass die Validator-Metadaten verifiziert sind (z. B. kein Sybil-Validator gesetzt).

Bei Prämienverträgen sollten Epochen nachverfolgt werden, um doppelte Belohnungen zu vermeiden.

10. Design zum Mitnehmen

Das epochenbasierte PoS-Modell von Sui erzwingt Determinismus, Leistungsisolierung und Delegationsflexibilität, was sich vom kontinuierlichen blockweisen Wechsel der Validatoren von EVM-Ketten unterscheidet. Entwickler intelligenter Verträge sollten Epochenübergänge als Grenzen des Zustandswechsels betrachten, wenn es um Logik geht, die von der Zeit, dem Ruf des Prüfers oder den Staking-Abläufen abhängt.

Lassen Sie mich wissen, ob Sie eine Vorlage für einen Move-Vertrag wünschen, der Epochendaten liest oder die Bedingungen validiert, die auf dem Einsatz basieren.

In Sui ist die Zeit in Abschnitte aufgeteilt, die Epochen genannt werden. Jede Epoche ist wie eine Sitzung, die standardmäßig etwa 24 Stunden dauert (dies kann geändert werden). Während einer Epoche verarbeiten Validatoren Transaktionen, verdienen Belohnungen und pflegen das Netzwerk. Wenn eine Epoche endet, finalisiert das System alles und geht zur nächsten über. Dieser Übergang beinhaltet eine kurze Pause, die sogenannte Reconfig-Zeit, die dem Netzwerk die Möglichkeit gibt, seinen internen Zustand sicher zu aktualisieren — so als würde man tief durchatmen, bevor die nächste Runde beginnt.

Diese Epochen sind von entscheidender Bedeutung, da sich in ihnen die Validator-Sets ändern können. Sui verwendet ein delegiertes PoS-Modell, sodass die Validatoren danach ausgewählt werden, wie viel SUI sie einsetzen und wie viel andere an sie delegieren. Um ein Validator zu werden, müssen Sie den Mindesteinsatz erreichen (z. B. 30 SUI), und um in der Gruppe der besten Validatoren zu bleiben, müssen Sie genügend delegierte Einsätze für sich gewinnen. Am Ende jeder Epoche überprüft das System diese Ranglisten und passt das Validator-Set automatisch an — es sind keine Hardforks oder manuelle Upgrades erforderlich.

Zur Konsensverarbeitung verwendet Sui ein Protokoll namens Narwhal und Bullshark für komplexe oder Shared-State-Transaktionen. Es gewährleistet Sicherheit, auch wenn sich einige Validatoren schlecht benehmen. Aber bei einfachen Transaktionen, die keine gemeinsam genutzten Objekte beinhalten, überspringt Sui den großen Konsens und führt sie parallel aus, wodurch alles schneller wird.

Validatoren erhalten Prämien in Form von Transaktionsgebühren und dem Speicherfonds. Wenn ein Validator betrügt — etwa wenn er mehrere widersprüchliche Nachrichten signiert —, kann er bestraft (gekürzt) werden, aber wie das funktioniert, wird von der Unternehmensleitung festgelegt, nicht fest codiert.

Unter der Haube verfolgt das System Epocheninformationen in einem speziellen On-Chain-Objekt. Dieses Objekt speichert Details wie die aktuelle Epochennummer, wann sie gestartet wurde und welche Validatoren aktiv sind. Entwickler kontrollieren dies nicht direkt, aber Sie können die aktuelle Epoche in Ihren Move-Smart-Verträgen mit epoch_time: :current_epoch (ctx) lesen.

Wenn du Verträge schreiben möchtest, die Epochenänderungen speichern oder auf sie reagieren, kannst du dein eigenes Objekt erstellen, um sie zu verfolgen. Es gibt ein Move-Beispielmodul, das zeigt, wie das geht. Dazu gehört auch, wie du die Epoche in deiner App-Logik aktualisierst oder liest.

Eine wichtige Sache, die Sie wissen sollten: Nur die Unternehmensleitung ist berechtigt, Funktionen auf Systemebene aufzurufen, z. B. das Hinzufügen eines neuen Validators zum Set. Als regulärer Entwickler können Sie diese Funktionen nicht direkt aus Ihrem Code heraus auslösen.

Um mit Epochen und Validatoren zu interagieren, können Sie die Sui-CLI verwenden. Sie können die aktuelle Epoche überprüfen, Ihre SUI an einen Validator weitergeben oder sogar das Verhalten von Validatoren im Localnet simulieren. Wenn Sie ein Testnetzwerk lokal ausführen, können Sie die Epochenlänge verkürzen (z. B. auf 10 Sekunden), um zu sehen, wie sich Ihre App bei Übergängen verhält.

Stellen Sie aus Sicherheits- und Testsicht sicher, dass Ihre App Epochenübergänge bewältigen kann. Das bedeutet, fehlgeschlagene Transaktionen, die während der Neukonfiguration aufgetreten sind, erneut zu versuchen und zu überprüfen, ob die Logik Ihres Vertrags auch dann noch gültig ist, wenn sich die Epoche ändert. Verfolgen Sie außerdem, auf welche Validatoren Sie setzen, und vermeiden Sie solche mit schlechter Verfügbarkeit oder schlechtem Verhalten.

Im Vergleich zu Ethereum, das bis zu einem Upgrade einen größtenteils festen Validatorsatz verwendet, ist das Validator-Set von Sui dynamisch und passt sich täglich an. Diese Flexibilität ist enorm — insbesondere für Anwendungsfälle wie DeFi-Pools, bei denen möglicherweise häufige Delegationsänderungen erforderlich sind —, aber sie bedeutet auch, dass Sie Ihre Logik um ein System herum entwerfen müssen, das ständig in Bewegung ist.

Sui unterstützt auch die parallele Ausführung von Transaktionen, die sich nicht überschneiden, wodurch die Engpässe des blockweisen Block-für-Block-Systems von Ethereum vermieden werden. Das ist ein großer Gewinn für großvolumige Apps wie NFT-Mints oder Wallet-Transaktions-Batching.

Da Sui jedoch den Zugriff auf einige Systemfunktionen einschränkt, müssen Sie im Gegensatz zum EVM-Stil „Alles jederzeit bereitstellen“ im Voraus planen, wenn Ihre Funktionen von Validatoren oder Epochen abhängen.

In Sui sind Epochen und Validator-Sets grundlegende Bestandteile des delegierten Proof-of-Stake (DPoS) -Konsensmodells. Eine Epoche ist ein fester Zeitraum, in dem eine bestimmte Gruppe von Validatoren für die Validierung von Transaktionen und die Sicherung des Netzwerks verantwortlich ist. Am Ende jeder Epoche kann auf der Grundlage von Staking-Aktivitäten und Verwaltungsentscheidungen eine neue Gruppe von Validatoren gebildet werden. Die Validatoren werden entsprechend der Anzahl der SUI-Tokens ausgewählt, die mit ihnen eingesetzt werden. Delegierte können ihre SUI einsetzen, um an der Sicherung des Netzwerks teilzunehmen und Belohnungen zu verdienen. Das Stimmrecht jedes Validators ist proportional zum Gesamtbetrag, auf den er gesetzt hat, was sich direkt auf den Konsens auswirkt.

Der Checkpoint-Mechanismus von Sui hilft dabei, Transaktionen zwischen den Validatoren abzuschließen, und gewährleistet einen deterministischen Statusverlauf. Änderungen am Validator, Stake-Updates und Änderungen der Protokollparameter werden erst zu Beginn einer neuen Epoche wirksam. Diese Logik des Epochenübergangs ist in den Move-Modulen des Sui-Systems kodiert und im Sui-System-Paket sichtbar. Entwickler können Epochen-Metadaten über die Sui-CLI mit Befehlen wie sui client call --function get_current_epoch überprüfen.

Im Gegensatz zu EVM-Ketten sind Änderungen am Prüfungssatz in Sui eng an das objektzentrierte Modell und die strengen Zugriffsregeln von Move gebunden, was dazu beiträgt, die Konsistenz und Sicherheit bei Übergängen aufrechtzuerhalten. Um Probleme bei der Bereitstellung zu vermeiden, sollten Entwickler Verträge so entwerfen, dass sie sorgfältig auf dynamische Validator-Informationen verweisen, insbesondere in Anwendungen wie Governance, Staking-Dashboards oder epochenübergreifenden Workflows.