####1. Principes fondamentaux de l'horloge Sui Clock

Pourquoi une horloge partagée ? Le modèle d'exécution parallèle de Sui signifie :

• Aucun ordre de blocage garanti → Impossible d'utiliser des numéros de bloc/des horodatages
• Clockest unobjet partagéfournissant du temps basé sur le consensus

Structure de base :

module sui::clock {  
    struct Clock has key {  
        id: UID,  
        timestamp_ms: u64,  
    }  
}  

Principales propriétés :

• Mis à jour toutes les2 secondes(configurable par les validateurs)
• Précision en millisecondes (contre les blocs d'environ 12 secondes d'Ethereum)
• Immuable : ne peut pas être modifié par des contrats

---

####2. Modèles d'utilisation pratiques

#####Vérification de l'heure de base

use sui::clock;  

public entry fn execute_if_ready(  
    clock: &Clock,  
    lock: &mut LockedAsset  
) {  
    assert!(clock.timestamp_ms >= lock.unlock_time, ELocked);  
    // Release assets  
}  

#####Application des délais

struct Auction has key {  
    id: UID,  
    end_time: u64, // Stored as Clock timestamp  
    highest_bid: u64  
}  

public entry fn bid(  
    auction: &mut Auction,  
    clock: &Clock,  
    bid_amount: u64  
) {  
    assert!(clock.timestamp_ms < auction.end_time, EAuctionEnded);  
    // Process bid  
}  

#####Actions verrouillées dans le temps

struct VestingSchedule has key {  
    id: UID,  
    start_time: u64,  
    cliff_duration: u64 // In milliseconds  
}  

public fun claimable_amount(  
    vesting: &VestingSchedule,  
    clock: &Clock  
): u64 {  
    let elapsed = clock.timestamp_ms - vesting.start_time;  
    // Linear vesting math  
}  

---

####3. Considérations avancées

#####Cohérence des éclates

• Tous les fragments affichent lemême horodatage d'horlogelors d'une transaction
• Pour les opérations cross-shard, passez en &Clocktant que référence d'objet partagée

#####Optimisation du gaz

• Stockez lestemps relatifs(par exempleduration_ms: u64) au lieu des temps absolus dans la mesure du possible
• Réutilisez la même Clockréférence pour toutes les fonctions

#####Gestion des erreurs

const MAX_CLOCK_DRIFT_MS: u64 = 3000; // 3s tolerance  

public fun validate_clock(clock: &Clock) {  
    assert!(tx_context::epoch(ctx) == clock.epoch(), EStaleClock);  
    assert!(clock.timestamp_ms <= tx_context::now_ms(ctx) + MAX_CLOCK_DRIFT_MS, EInvalidTime);  
}  

---

####4. Stratégies de test

#####Une horloge simulée dans les tests

#[test_only]  
fun mock_clock(timestamp_ms: u64): Clock {  
    Clock { id: test_scenario::new_object(ctx), timestamp_ms }  
}  

#[test]  
fun test_vesting() {  
    let clock = mock_clock(1000);  
    let vesting = VestingSchedule { start_time: 0, ... };  
    // Test claimable amount at t=1000  
}  

#####Tests de transition d'époque

#[test]  
fun test_clock_epoch_change() {  
    let mut scenario = test_scenario::begin(...);  
    // Advance epoch  
    test_scenario::next_epoch(&mut scenario);  
    let clock = test_scenario::take_shared<Clock>(scenario);  
    assert!(clock.epoch() == 1, EEpochError);  
}  

Si vous travaillez sur une logique sensible au facteur temps, comme les enchères ou les calendriers d'acquisition dans Sui Move, le sui::clockmodule est votre moyen de référence pour suivre le temps. Sui ne s'appuie pas sur des horodatages de blocs comme Ethereum ou Solana, car il vise une exécution déterministe et un parallélisme. C'est pourquoi il utilise unobjet Clock partagé, qui est mis à jour une fois par point de contrôle et vous donne une source de temps canonique.

Vous interagissez avec le temps en lisant cet objet Clock partagé (généralement transmis aux fonctions de saisie) à l'aide declock.timestamp. Cette valeur est mise à jour environ toutes les secondes et vous donne l'horodatage UNIX actuel en secondes. Bien qu'il ne soit pas lié à chaque bloc comme dans EVM, il est suffisamment précis pour des cas d'utilisation pratiques tels que le déverrouillage de jetons ou l'expiration des enchères, mais pas une précision de l'ordre de la microseconde.

Lorsque vous créez une logique basée sur le temps,transmettez toujours l'objet Clock explicitementafin que votre fonction Move puisse le lire et comparer les horodatages aux délais que vous avez enregistrés. Pour éviter un comportement rigide, utilisez des délais de grâce ou une marge de manœuvre dans vos comparaisons (if current_time > unlock_time + buffer), et évitez de vous fier aux secondes exactes.

Pour les tests, Sui vous permet desimuler l'horloge lors de tests unitairesen créant votre propre instance de l'objet partagé avec un horodatage personnalisé. De cette façon, vous pouvez simuler les conditions futures sans avoir besoin de temps réel pour passer. Construisez simplement l'horloge manuellement avec une valeur définie dans vos #[test]fonctions.

Si vous vous sentez limité, c'est probablement dû à la façon dont Sui protège l'horloge contre les mutations en dehors des points de contrôle. Vous devrez concevoir vos modules en fonction des horodatages en entrée et les lire à partir de l'objet partagé officiel. Évitez de créer votre propre source de temps, car cela brise le déterminisme.

🔗 En savoir plus sur le module Sui Clock