Attribués une fois après une réponse correcte.
Trouver l’état qui nécessite une coordination
À connaître avant : De la signature au règlement
Parcours de lecture · 41 / 41 · Intermédiaire
Sui est un Layer 1 programmable utilisant Move et un modèle de données centré sur les objets.
Un état organisé en objets
Sui est un Layer 1 programmable utilisant Move et un modèle de données centré sur les objets. SUI est son actif natif, utilisé pour le gas et le staking. Un objet n’est pas seulement une image ou un NFT : c’est un élément d’état on-chain avec identité, type et règles de propriété. Les coins et ressources d’une application peuvent également être des objets.
La propriété change les règles
La propriété influence les transactions capables d’utiliser ou de modifier un objet. Un objet appartenant à une adresse dépend de l’autorité de son propriétaire. Un objet partagé est accessible à plusieurs utilisateurs selon les règles de son programme Move. Un objet immuable ne peut plus être modifié. « Partagé » ne veut donc pas dire que chacun peut modifier librement chaque champ.
Trouver la dépendance commune
La question utile est de savoir quel état deux opérations doivent modifier. Des objets indépendants peuvent permettre un travail indépendant ; deux opérations touchant le même état partagé nécessitent une coordination. Le modèle objet ne signifie ni parallélisme universel, ni disparition des conflits, ni exactitude automatique de la logique applicative.
Un billet et la dernière place disponible
Comparez un billet de concert détenu individuellement et un inventaire partagé de places. Transférer un billet existant et réserver la dernière place sont deux opérations différentes. La seconde doit respecter une disponibilité commune. Lisez propriétaire de l’objet et permissions du programme avec l’action demandée : une interface rassurante ne prouve pas ce que fera la transaction signée.
Comprendre en profondeur
Imaginez deux personnes transférant chacune leur propre billet. Les objets diffèrent : ces actions ne se disputent pas l’état du même billet. Imaginez ensuite les deux personnes réservant la dernière place du même inventaire partagé. Le programme doit faire respecter cette disponibilité. La propriété aide à définir qui peut demander une modification ; la logique du programme détermine laquelle est valide.
Limites et erreurs fréquentes
Le billet est un modèle d’application fictif, pas la description d’une billetterie réelle. Les objets partagés peuvent imposer des permissions. Une chaîne orientée objet nécessite toujours consensus, programmation rigoureuse et signature sécurisée.
Le mécanisme en un schéma
- 01Identité de l’objet
- 02Propriété
- 03Opération permise
- 04Dépendances d’état
Ces repères représentent des notions liées, pas nécessairement des étapes successives.
Deux transferts de billets distincts ont des états séparés. Deux réservations de la même dernière place touchent le même inventaire partagé et doivent respecter une disponibilité unique.
Lire l’explication
Imaginez deux personnes transférant chacune leur propre billet. Les objets diffèrent : ces actions ne se disputent pas l’état du même billet. Imaginez ensuite les deux personnes réservant la dernière place du même inventaire partagé. Le programme doit faire respecter cette disponibilité. La propriété aide à définir qui peut demander une modification ; la logique du programme détermine laquelle est valide.
Replacez le mécanisme dans son contexte
Un inventaire partagé contient une seule place restante. Deux demandes tentent chacune de passer le compteur de un à zéro et d’émettre un billet. Les deux demandes portent des signatures valides.
Appliquer dans l’atelier →Ce que ce mécanisme ne garantit pas
Le billet est un modèle d’application fictif, pas la description d’une billetterie réelle. Les objets partagés peuvent imposer des permissions. Une chaîne orientée objet nécessite toujours consensus, programmation rigoureuse et signature sécurisée.
La distinction qui change l’analyse
Deux demandes signées peuvent être autorisées tout en se disputant la dernière place d’un inventaire partagé. Propriété et signatures répondent à la question de l’autorité ; le programme doit encore préserver la disponibilité.
À vous de l’expliquer
Reprenez le cas ci-dessus. Nommez ce qui est établi, ce qui reste à vérifier et la preuve qui permettrait de conclure. Une réponse solide traite les deux côtés du schéma.
Appliquer la leçon à un cas
Un inventaire partagé contient une seule place restante. Deux demandes tentent chacune de passer le compteur de un à zéro et d’émettre un billet. Les deux demandes portent des signatures valides.
La règle de disponibilité partagée doit tenir. Deux signatures valides ne créent pas une seconde place. Coordination et contrôles du programme doivent empêcher les deux opérations de consommer la même disponibilité finale.
Les termes de cette leçon
- Gas
- Une mesure des ressources d’exécution ; quantité de gas et prix unitaire sont deux données distinctes.
Préparer une note de correction
Décrivez le passage et la correction proposée. Vous pourrez copier cette note pour la partager ; rien n’est envoyé. N’incluez aucune donnée personnelle ou confidentielle.