Le mécanisme de preuve d'enjeu (PoS) de Sui intègre des époques et des ensembles de validateurs pour garantir la sécurité et le consensus du réseau, ce qui diffère considérablement des chaînes EVM. Voici une explication détaillée adaptée à vos objectifs de développement :

Époques en Sui

Sui fonctionne selon des périodes discrètes appelées époques, chacune d'une durée d'environ 24 heures (configurable, par défaut, 864 000 emplacements à environ 150 ms par emplacement). Epochs gère les modifications apportées aux ensembles de validateurs et les paramètres de consensus :

• Structure : Chaque époque commence par une transaction système définissant les paramètres (par exemple, les seuils de mise, les récompenses) et se termine par un point de contrôle finalisant les changements d'état.
• Transition : les validateurs proposent une nouvelle époque via un appel de déplacement du système, nécessitant un accord 2f+1 (où f est le nombre maximum de validateurs défectueux). Cela déclenche une période de reconfiguration au cours de laquelle le réseau s'arrête brièvement.
• Objectif : Epochs permet la mise à jour dynamique des ensembles de validateurs, la redélégation des enjeux et l'ajustement des paramètres sans interrompre la chaîne.

Ensembles de validateurs et points de vente

Sui utilise un modèle de PoS délégué dans lequel les validateurs sont sélectionnés sur la base de jetons SUI jalonnés :

• Élection : les validateurs doivent miser un montant minimum (par exemple, 30 SUI, ajustables) et attirer des délégations de la part des utilisateurs. Les N meilleurs validateurs (par exemple, 100) en termes de mise totale forment l'ensemble actif.
• Consensus : Sui utilise un protocole Byzantine Fault Tolerant (BFT) (Narwhal/Bullshark) pour les objets partagés, garantissant 2f+1 validateurs honnêtes sur un total de 3f+1. Pour les transactions simples, il utilise un traitement parallèle sans consensus total.
• Récompenses et slashing : les validateurs gagnent des récompenses grâce aux frais de transaction et à la redistribution des fonds de stockage, proportionnellement à la mise. Un mauvais comportement (par exemple, une double signature) entraîne des barres obliques, bien que les détails soient définis par la gouvernance.
• Rotation : à la fin de l'époque, les changements de mise déclenchent un nouvel ensemble de validateurs, les validateurs inactifs étant fermés et les nouveaux entrant en fonction du classement des mises.

Cela contraste avec les ensembles de validateurs statiques d'EVM dans les chaînes PoS comme Ethereum, où les modifications se produisent via des hard forks ou des mises à niveau.

Concepts architecturaux

• Objet d'état du système : suit les données d'époque (par exemple, heure de début, ensemble de validateurs) et est mis à jour via les mouvements du système.
• Parallélisme : le modèle objet de Sui permet aux transactions ne se chevauchant pas de contourner le consensus, réduisant ainsi les goulots d'étranglement liés à l'époque par rapport à l'exécution séquentielle d'EVM.
• Temps de reconfiguration : une courte pause (secondes) pendant les transitions d'époque garantit la cohérence des états, un compromis unique en termes de flexibilité.

Déplacer la structure du code

Les mouvements du système gèrent les transitions d'époque, mais les développeurs peuvent interagir avec les données d'époque. Exemple :

déplacer module my_module : :epoch_tracker { utilisez sui : :epoch_time : :EpochTime ; utilisez sui : :tx_context : :TxContext ;

la structure publique EpochData a une clé, store { identifiant : UID, époque_actuelle : u64, }

entrée publique run update_epoch (données : &mut EpochData, epoch : u64, ctx : &mut TxContext) { data.current_epoch = époque ; //Logique supplémentaire basée sur l'époque }

entrée publique fun create_epoch_tracker (ctx : &mut TxContext) { let data = EpochData { identifiant : object : :new (ctx), époque_actuelle : époche_heure : :époque_actuelle (ctx), } ; transfer : :transfer (données, tx_context : :sender (ctx)) ; } }

• Points clés : utilisez epoch_time : :current_epoch pour accéder à l'époque actuelle. Les déplacements du système (par exemple, sui_system : :request_add_validator) sont limités à la gouvernance.
• Sécurité : validez les données d'époque pour éviter toute manipulation lors de la reconfiguration.

Utilisation de la CLI

Gérez les interactions entre les validateurs et les données d'époque via Sui CLI :

• Vérifiez l'époque : frapper sur le client get-epoch-info

• Sortie : époque actuelle, heure de début, ensemble de validateur.

• Stake SUI (en tant que délégant) : frapper mise du client sui --montant 100 --validateur --gas-budget 1000000

• Surveillez : Solde insuffisant ou adresse de validation non valide.

• Ajout d'un validateur de demande (gouvernance uniquement, simulé sur localnet) : frapper appel client sui --package --module sui_system --function request_add_validator --args --gas-budget 1000000

• Remarque : nécessite l'ID du package système et le rôle de gouvernance.

• Configuration du réseau local : frapper validateur de test Sui-With-Faucet

• Simulez les transitions d'époque en ajustant la configuration (par exemple, raccourcissez la durée de l'époque).

Meilleures pratiques et principes de sécurité

1. Epoch-Aware Logic : Concevez des contrats pour gérer les pauses de reconfiguration (par exemple, les nouvelles tentatives de transactions).
2. *Surveillance des enjeux * : utilisez la CLI ou le SDK pour suivre les enjeux des validateurs, en garantissant la délégation à des nœuds fiables.
3. Tester : simulez les transitions d'époque sur le réseau local avec sui-test-validator --epoch-duration-ms 10000 pour tester le comportement.

• Erreur courante : la transaction a expiré pendant la reconfiguration : augmentez le délai ou réessayez.

4. Sécurité : évitez de vous fier à des données spécifiques à une époque sans validation, car les reconfigurations peuvent modifier l'état.
5. Conditions réalistes : testez avec différentes distributions de mises sur testnet pour imiter les modifications apportées aux ensembles de validateurs.

Différences par rapport à l'EVM et à l'impact sur le développement

• Validateurs dynamiques : EVM PoS (par exemple, Ethereum) corrige les validateurs jusqu'à la mise à niveau, tandis que la rotation basée sur l'époque de Sui favorise l'adaptabilité, idéale pour les pools de liquidités DeFi nécessitant des ajustements fréquents.
• Parallélisme : le parallélisme au niveau des objets de Sui réduit la surcharge d'époque, contrairement aux limites basées sur les blocs d'EVM, ce qui profite au minting de NFT ou aux opérations par lots de portefeuilles.
• Développement : les restrictions de déplacement du système de Move nécessitent une interaction de gouvernance, contrairement au déploiement de contrats ouverts d'EVM, qui nécessite une planification minutieuse des fonctionnalités liées aux validateurs.

Erreurs et correctifs courants

• Ignorer la reconfiguration : en supposant que le fonctionnement continu échoue pendant les transitions. Correctif : implémentez la logique des nouvelles tentatives.
• Mise invalide : Un jalonnement inférieur au minimum déclenche des erreurs. Correctif : consultez get-epoch-info pour les seuils.
• Incompatibilité réseau : l'utilisation de la CLI du réseau principal sur le réseau de test échoue. Correctif : Alignez avec le réseau cible (par exemple, sui client switch --env testnet).

Cela s'applique aux contrats intelligents (logique basée sur l'époque), aux NFT (minting dépendant du validateur), aux portefeuilles (suivi des mises) et à la DeFi (pools de liquidités dynamiques). Effectuez des tests approfondis sur localnet/testnet pour garantir la robustesse au-delà des frontières d'époque.

Sui travaille sur un système temporel appelé epochs. Chaque époque dure environ 24 heures par défaut, mais cela peut être modifié. Vous pouvez imaginer les époques comme des parties : au début, le système définit les règles, la liste des validateurs et les paramètres de récompense ; à la fin, il bloque l'état et prépare le tour suivant. Lorsque vous passez d'une époque à une autre, il y a une courte pause appelée temps de reconfiguration, qui dure quelques secondes, au cours de laquelle le réseau s'arrête brièvement pour se mettre à jour en toute sécurité.

Parlons maintenant des validateurs. Sui utilise un système de preuve de participation (PoS) délégué. Les validateurs doivent miser un montant minimum de SUI (disons 30 jetons) et attirer davantage de délégations de la part des utilisateurs pour figurer dans la liste des N premiers, qui définit qui doit figurer dans le jeu de validateurs actifs pour cette époque. Si votre validateur ne figure pas en haut de la liste, il sera expulsé lors de la prochaine transition d'époque. Le montant des mises et la délégation déterminent donc automatiquement la rotation des validateurs, contrairement à Ethereum, où les ensembles de validateurs sont pratiquement fixes, sauf en cas de mise à niveau du réseau ou de proposition de gouvernance.

Dans Sui, le système Proof-of-Stake (PoS) s'articule autour de ce que l'on appelle des époques. Considérez-les comme des fenêtres temporelles dans lesquelles un ensemble de validateurs reste bloqué pour faire fonctionner le réseau. Chaque époque dure environ 24 heures par défaut, mais elle est configurable. Lorsqu'une époque commence, le système définit des règles telles que les seuils de mise et les personnes faisant partie du groupe de validateurs. À la fin, le système termine l'état proprement et se prépare pour le suivant.

C'est là que cela devient intéressant : lors du passage d'une époque à l'autre, le réseau s'arrête pendant quelques secondes. Cette pause est appelée temps de reconfiguration et permet au système de faire pivoter les validateurs en toute sécurité ou de modifier les paramètres internes. Votre application doit le savoir, car les transactions envoyées pendant cette courte période peuvent échouer ou expirer.

La sélection du validateur est dynamique. Si vous utilisez un validateur, vous devez staker certaines SUI et demander à d'autres de vous déléguer des tâches. Le réseau sélectionne automatiquement les meilleurs validateurs en fonction de leur mise totale et constitue l'ensemble actif à chaque époque. Si quelqu'un met plus que vous, vous risquez d'être expulsé au tour suivant. Les délégants peuvent également déplacer leur mise à chaque époque, donc c'est fluide. Contrairement à Ethereum où les modifications du validateur nécessitent des mises à niveau du protocole, Sui s'en occupe tous les jours.

Le consensus fonctionne également différemment. Sui utilise Narwhal et Bullshark pour les transactions d'objets partagés, qui nécessitent une coordination. Mais si votre application traite d'objets détenus, tels que des portefeuilles personnels, elle ignore le consensus total et traite les choses en parallèle. Cela change la donne, car cela signifie que vos transactions n'attendent pas derrière des transactions non liées, comme c'est le cas sur Ethereum.

Dans le code Move, vous pouvez récupérer l'époque actuelle en utilisant epoch_time : :current_epoch (ctx). Par exemple, si vous créez un module qui réagit aux changements d'époque, vous pouvez créer votre propre objet pour stocker et mettre à jour les valeurs d'époque. Voici un aperçu de base de ce à quoi cela ressemble :

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;
    }
}

Dans le réseau Sui, les époques et les ensembles de validateurs sont des éléments centraux de son modèle de consensus de preuve d'enjeu délégué (DPoS). Une époque en Sui est une fenêtre temporelle de durée fixe (par exemple, 24 heures) pendant laquelle un ensemble de validateurs particulier est responsable du traitement des transactions et de la production de blocs. Chaque époque commence par une phase de reconfiguration au cours de laquelle l'ensemble de validateurs peut changer en fonction des entrées de jalonnement de l'époque précédente.

1. Époques et rotation des validateurs

Chaque époque possède un ensemble de validateurs unique, déterminé par la mise totale déléguée à chaque validateur.

Les délégués confient leurs jetons SUI à des validateurs, ce qui détermine qui rejoindra l'ensemble actif à l'époque suivante.

À la fin d'une époque, le réseau s'arrête brièvement pour reconfigurer, finaliser le point de contrôle de l'époque et passer au jeu de validateurs suivant.

2. Structure de l'ensemble de validateurs

L'ensemble de validateurs est stocké dans un objet Move, géré par le module système 0x3 : :sui_system.

Chaque validateur possède des métadonnées, notamment sa clé publique, le montant de sa mise, sa commission et son adresse réseau.

validateur de structure { métadonnées : ValidatorMetadata, pouvoir_de vote : u64, prix_du gaz : 64 euros, taux de commission : u64, ... }

3. Staking et délégation

Les stakers interagissent avec le module du système Sui via la CLI ou le SDK pour déléguer la participation :

mise du client sui --montant 1000000000 --validateur <VALIDATOR_ADDRESS>

Les jetons mis en jeu sont verrouillés et influencent la mise totale du validateur pour l'époque suivante.

Les récompenses sont distribuées aux limites de l'époque et peuvent être réclamées via la méthode withdraw_rewards.

4. Interaction avec les mouvements

La fonction sui_system : :request_epoch_change est appelée automatiquement pour alterner les validateurs.

Les contrats intelligents ne contrôlent pas directement les époques mais peuvent accéder aux informations du validateur pour la gouvernance ou la logique de jalonnement à l'aide du module sui_system.

5. Utilisation du CLI/SDK

Pour interroger l'époque et les validateurs actuels :

appel client sui --package 0x3 --module sui_system --function get_current_epoch appel client sui --package 0x3 --module sui_system --function get_validator_set

À partir du SDK :

const epochInfo = await Provider.getLatestSuisystemState () ; console.log (EpochInfo.epoch, EpochInfo.ActiveValidators) ;

6. Possibilité de gouvernance en chaîne

La structure de Sui permet une logique de jalonnement avancée ou des contrats tenant compte de l'époque, par exemple une logique d'acquisition ou de rééquilibrage déclenchée par l'époque.

7. Pièges courants

L'utilisation d'adresses de validation périmées peut entraîner l'échec du jalonnement.

Une délégation trop proche de la fin d'une époque peut retarder les effets jusqu'au cycle suivant.

Les contrats ne peuvent pas accéder directement à l'heure mais doivent utiliser les données d'horloge ou d'époque du système.

8. Tests et meilleures pratiques

Sur localnet, vous pouvez simuler des transitions d'époque en appelant :

sui genesis --epoch-duration-ms 10000

Surveillez les reconfigurations avec l'événement EpochChangeEvent.

9. Sûreté

Assurez-vous que les métadonnées du validateur sont vérifiées (par exemple, aucun validateur sybil n'est défini).

Les contrats de récompenses doivent suivre les époques pour éviter les doubles récompenses.

10. Design à emporter

Le modèle PoS basé sur l'époque de Sui applique le déterminisme, l'isolation des performances et la flexibilité de la délégation, ce qui diffère de la commutation continue des validateurs bloc par bloc des chaînes EVM. Les développeurs de contrats intelligents devraient traiter les transitions d'époque comme des limites de changement d'état pour une logique qui dépend du temps, de la réputation du validateur ou des flux de jalonnement.

Faites-moi savoir si vous souhaitez un modèle de contrat Move qui lit les données d'époque ou valide les conditions basées sur les enjeux.

En Sui, le temps est divisé en morceaux appelés époques. Chaque époque est comme une session qui dure environ 24 heures par défaut (cela peut être modifié). À une époque, les validateurs traitent les transactions, gagnent des récompenses et entretiennent le réseau. À la fin d'une époque, le système finalise tout et passe à la suivante. Cette transition implique une courte pause, appelée temps de reconfiguration, qui permet au réseau de mettre à jour son état interne en toute sécurité, un peu comme si vous respiriez profondément avant de commencer le cycle suivant.

Ces époques sont cruciales car c'est à ce moment-là que les ensembles de validateurs peuvent changer. Sui utilise un modèle de PoS délégué, de sorte que les validateurs sont sélectionnés en fonction de la quantité de SUI qu'ils mettent en jeu et de la quantité que les autres leur délèguent. Pour devenir un validateur, vous devez atteindre la mise minimale (par exemple, 30 SUI), et pour rester dans le top des validateurs, vous devez attirer suffisamment de mise déléguée. À la fin de chaque époque, le système vérifie ces classements et ajuste automatiquement le réglage du validateur : aucun hard fork ou mise à niveau manuelle n'est nécessaire.

Pour gérer le consensus, Sui utilise un protocole appelé Narwhal et Bullshark pour les transactions complexes ou à états partagés. Il garantit la sécurité même si quelques validateurs se comportent mal. Mais pour les transactions simples qui n'impliquent pas d'objets partagés, Sui évite les consensus lourds et les exécute en parallèle, ce qui accélère le tout.

Les validateurs gagnent des récompenses grâce aux frais de transaction et au fonds de stockage. Si un validateur triche, par exemple en signant plusieurs messages contradictoires, il peut être pénalisé (barre oblique), mais son fonctionnement est défini par la gouvernance et non codé en dur.

Sous le capot, le système suit les informations d'époque dans un objet spécial en chaîne. Cet objet stocke des informations telles que le numéro d'époque actuel, sa date de démarrage et les validateurs actifs. Les développeurs ne contrôlent pas cela directement, mais vous pouvez lire l'époque actuelle dans vos contrats intelligents Move à l'aide de epoch_time : :current_epoch (ctx).

Si vous souhaitez rédiger des contrats qui mémorisent ou réagissent aux changements d'époque, vous pouvez créer votre propre objet pour le suivre. Un exemple de module Move explique comment procéder, notamment comment mettre à jour ou lire l'époque dans la logique de votre application.

Une chose importante à savoir : seule la gouvernance est autorisée à appeler des fonctions au niveau du système, comme l'ajout d'un nouveau validateur à l'ensemble. En tant que développeur régulier, vous ne pouvez pas les déclencher directement à partir de votre code.

Pour interagir avec les époques et les validateurs, vous pouvez utiliser la CLI Sui. Vous pouvez vérifier l'époque actuelle, attribuer votre SUI à un validateur ou même simuler le comportement du validateur sur le réseau local. Si vous exécutez un réseau de test localement, vous pouvez raccourcir la durée de l'époque (par exemple, à 10 secondes) pour voir comment votre application se comporte pendant les transitions.

Du point de vue de la sécurité et des tests, assurez-vous que votre application peut gérer les transitions d'époque. Cela implique de réessayer les transactions qui ont échoué pendant la période de reconfiguration et de valider que la logique de votre contrat est toujours valable lorsque l'époque change. Suivez également les validateurs que vous utilisez et évitez ceux dont la disponibilité ou le comportement sont médiocres.

Comparé à Ethereum, qui utilise un ensemble de validateurs essentiellement fixe jusqu'à une mise à niveau, l'ensemble de validateurs de Sui est dynamique et s'ajuste tous les jours. Cette flexibilité est puissante, en particulier pour des cas d'utilisation tels que les pools DeFi, qui peuvent nécessiter de fréquents changements de délégation, mais cela signifie également que vous devez concevoir votre logique autour d'un système toujours en mouvement.

Sui prend également en charge l'exécution parallèle pour les transactions ne se chevauchant pas, ce qui évite les blocages du système bloc par bloc d'Ethereum. C'est une grande victoire pour les applications à volume élevé, telles que les NFT Mints ou le traitement par lots de transactions de portefeuille.

Mais comme Sui limite l'accès à certaines fonctions du système, contrairement au style « déployez n'importe quoi à tout moment » d'EVM, vous devrez planifier à l'avance si vos fonctionnalités dépendent de validateurs ou d'époques.

Dans Sui, les époques et les ensembles de validateurs sont des éléments fondamentaux de son modèle de consensus de preuve de participation déléguée (DPoS). Une époque est une période fixe pendant laquelle un ensemble spécifique de validateurs est chargé de valider les transactions et de sécuriser le réseau. À la fin de chaque époque, un nouvel ensemble de validateurs peut être créé en fonction de l'activité de jalonnement et des décisions de gouvernance. Les validateurs sont sélectionnés en fonction de la quantité de jetons SUI qui leur sont attribués, et les délégants peuvent miser leur SUI pour participer à la sécurisation du réseau et à l'obtention de récompenses. Le pouvoir de vote de chaque validateur est proportionnel au montant total qui lui est misé, ce qui influence directement le consensus.

Le mécanisme de point de contrôle de Sui permet de finaliser les transactions entre les validateurs et garantit une progression déterministe de l'état. Les modifications du validateur, les mises à jour des enjeux et les modifications des paramètres de protocole ne prennent effet qu'au début d'une nouvelle époque. Cette logique de transition d'époque est codée dans les modules Move du système Sui et visible dans le package sui-system. Les développeurs peuvent inspecter les métadonnées d'époque via la CLI Sui à l'aide de commandes telles que sui client call --function get_current_epoch.

Contrairement aux chaînes EVM, les modifications apportées aux ensembles de validateurs dans Sui sont étroitement liées au modèle centré sur l'objet et aux règles d'accès strictes de Move, ce qui permet de maintenir la cohérence et la sécurité pendant les transitions. Pour éviter les problèmes de déploiement, les développeurs doivent concevoir des contrats de manière à référencer avec soin les informations des validateurs dynamiques, en particulier dans des applications telles que la gouvernance, les tableaux de bord de jalonnement ou les flux de travail interépoques.