@Dusk
Un détail dans le livre blanc de Dusk m’a arrêté net pendant ma lecture.
Le contrat de licence de leur Citadel ne se contente pas d’enregistrer qui détient une licence. Il suit si cette licence est actuellement valable, active ou expirée — pas seulement au moment où elle a été délivrée.
C’est une question différente de « qui êtes-vous ». C’est « êtes-vous encore autorisé à faire cela, tout de suite ».
La plupart des systèmes d’identité répondent une fois à la première question, puis s’arrêtent là.
La version de Dusk prend en charge la révocation et le renouvellement, si bien qu’un droit accordé aujourd’hui n’est pas censé exister demain. Cela reflète la façon dont les licences fonctionnent réellement hors chaîne — pour échanger, pratiquer, opérer — rien n’est permanent, tout est vérifiable.
Mettre cet état d’autorisation directement sur la chaîne, au lieu de le laisser dans le back-office de quelqu’un, c’est ce qui donne l’impression d’être plus proche d’une infrastructure juridique réelle qu’une fonctionnalité crypto typique.
Cela dit, un cycle de vie n’est aussi bon que la personne (ou l’équipe) qui le gère. Qui décide quand une licence est révoquée, et avec quelle rapidité cette décision atteint-elle la chaîne ?
Le contrat peut suivre l’état avec précision, mais il hérite tout de même de chaque défaut du processus qui l’alimente.
Le code applique une règle instantanément. Il ne peut pas garantir que les humains derrière cette règle l’ont correctement comprise, ni que l’exécution correspond à ce que la règle était censée accomplir.
C’est la leçon la plus importante, au-delà de Dusk en particulier. Mettre un processus on-chain le rend transparent et exécutable.
Mais cela ne le rend pas automatiquement correct. Il faut comprendre comment un système fonctionne réellement avant de lui confier quoi que ce soit d’important.
La compréhension vaut mieux que la confiance aveugle, à chaque fois. Continuez à lire les clauses en petits caractères — c’est généralement là que vit la vraie conception.
#dusk @Dusk $DUSK
Un détail dans le livre blanc de Dusk m’a arrêté net pendant ma lecture.
Le contrat de licence de leur Citadel ne se contente pas d’enregistrer qui détient une licence. Il suit si cette licence est actuellement valable, active ou expirée — pas seulement au moment où elle a été délivrée.
C’est une question différente de « qui êtes-vous ». C’est « êtes-vous encore autorisé à faire cela, tout de suite ».
La plupart des systèmes d’identité répondent une fois à la première question, puis s’arrêtent là.
La version de Dusk prend en charge la révocation et le renouvellement, si bien qu’un droit accordé aujourd’hui n’est pas censé exister demain. Cela reflète la façon dont les licences fonctionnent réellement hors chaîne — pour échanger, pratiquer, opérer — rien n’est permanent, tout est vérifiable.
Mettre cet état d’autorisation directement sur la chaîne, au lieu de le laisser dans le back-office de quelqu’un, c’est ce qui donne l’impression d’être plus proche d’une infrastructure juridique réelle qu’une fonctionnalité crypto typique.
Cela dit, un cycle de vie n’est aussi bon que la personne (ou l’équipe) qui le gère. Qui décide quand une licence est révoquée, et avec quelle rapidité cette décision atteint-elle la chaîne ?
Le contrat peut suivre l’état avec précision, mais il hérite tout de même de chaque défaut du processus qui l’alimente.
Le code applique une règle instantanément. Il ne peut pas garantir que les humains derrière cette règle l’ont correctement comprise, ni que l’exécution correspond à ce que la règle était censée accomplir.
C’est la leçon la plus importante, au-delà de Dusk en particulier. Mettre un processus on-chain le rend transparent et exécutable.
Mais cela ne le rend pas automatiquement correct. Il faut comprendre comment un système fonctionne réellement avant de lui confier quoi que ce soit d’important.
La compréhension vaut mieux que la confiance aveugle, à chaque fois. Continuez à lire les clauses en petits caractères — c’est généralement là que vit la vraie conception.
#dusk @Dusk $DUSK
