Registre partagé
Des participants conservent ou consultent un historique selon le modèle du réseau. Les droits, les règles et les responsabilités restent propres à ce modèle.
Blockchain & DLT
Comprendre les registres distribués, leurs usages et leurs limites.
SwissTokint propose des ressources d’apprentissage et de recherche ouverte sur la blockchain et les DLT. Nous distinguons le fonctionnement d’un registre de la vérité des données qui y sont inscrites.
Fondamentaux
Un registre partagé ne prouve pas tout.
Une blockchain ou un DLT coordonne des écritures entre des participants selon des règles communes. Il peut rendre certaines écritures vérifiables dans le cadre du réseau, sans rendre automatiquement un fait vrai, utile ou légal.
Transactions, règles et finalité
Les transactions proposent des changements d’état. Les nœuds appliquent les règles du protocole et la finalité dépend du réseau, de ses mécanismes et de son contexte.
Réseau, actif et application
L’infrastructure, la représentation d’un actif et l’application qui l’utilise sont trois rôles distincts. Les confondre masque des choix de gouvernance et de sécurité.
Usages responsables
La technique ne remplace pas le discernement.
Un usage responsable commence par la vérification du contexte et par des décisions humaines explicites. Cette page est éducative : elle ne demande aucune interaction avec une clé, un identifiant d’accès ou un actif.
Vérifier le contexte
Identifier la source, la version, le réseau, le destinataire et l’action envisagée avant de se fier à une information ou à une interface.
Protéger les secrets
Ne pas partager une phrase de récupération, une clé privée ou un code de connexion. Une demande pressante ou incohérente est un signal pour s’arrêter et vérifier.
Garder les décisions séparées
Une ressource pédagogique explique des mécanismes et des limites ; elle ne remplace ni une décision personnelle, ni un contrôle indépendant, ni un conseil spécialisé.
Recherche ouverte
Documenter les méthodes avant d’élargir les promesses.
Les travaux publics distinguent une intention, des travaux en cours et des résultats effectivement documentés. Les limites font partie du résultat.
Sources et versions
Relier une affirmation à une source, une version et un périmètre permet de comprendre ce qui a été examiné et ce qui reste hors champ.
Objectifs et limites déclarés
Décrire ce qu’un prototype cherche à explorer sans présenter une hypothèse comme un résultat établi, une garantie ou une adoption.
Éléments publiés
Publier seulement des éléments que chacun peut consulter, relier à leur contexte et lire avec leurs limites explicites.
Exemple documenté
POM-RX v0.1
POM-RX v0.1 — spécification de travail publique et prototype testé.
POM-RX v0.1 explore une chaîne de trois reçus liés — préflight, accusé de réception d’exécution et réconciliation. Le vérificateur de référence Node/TypeScript contrôle la structure fournie, l’ordre des phases, certains champs partagés et les liens de hachage entre reçus.
Cette vérification n’établit ni chronologie fiable, ni vérité d’un fait externe, ni consommation d’une autorisation, ni observation indépendante, ni blocage de l’exécution.
Limites
Choisir un registre distribué seulement lorsqu’il apporte une valeur vérifiable.
La technologie n’élimine ni les risques de données, ni les obligations de gouvernance, ni les responsabilités humaines. Un système plus simple peut être préférable selon le besoin.
Un registre n’est pas la vérité
Une écriture peut être cohérente avec les règles du réseau sans que la donnée d’origine soit exacte, complète, utile ou légale.
Les conditions varient selon le réseau
La finalité, les permissions, les coûts, la confidentialité et les règles de participation dépendent de l’architecture retenue.
Tous les problèmes ne nécessitent pas une DLT
Une gouvernance claire, des procédures vérifiables ou une architecture centralisée peuvent être plus adaptées qu’un registre distribué.