\u003cm-9/\u003e
Bien qu'un protocole permettant une computation on-chain arbitraire tel que Dusk Network puisse agir en tant qu'hôte d'un nombre virtuellement illimité d'applications uniques, nous avons conçu Dusk Network avec un ensemble spécifique de cas d'utilisation à l'esprit. Plus précisément, Dusk Network a été principalement conçu avec la tokenisation de sécurité conforme à la réglementation et la gestion du cycle de vie à l'esprit. Les détails de la norme de tokenisation de sécurité dépassent le cadre de ce document. Nous encourageons les lecteurs à se référer à [Mah21] pour un examen approfondi de cette norme de Contrat de Sécurité Confidentiel (XSC). De plus, une Norme de Jeton Confidentiel a été créée pour permettre une interaction fluide entre les actifs non régulés et régulés au sein du protocole, sans compromettre la vie privée des utilisateurs interagissant. Cela permet également au protocole Dusk Network d'agir en tant que sidechain préservant la vie privée pour tout autre protocole Layer 1 existant via des solutions d'interopérabilité de confiance ou minimisée.
Protocole abstrait
L'objectif de cette section est d'établir les exigences fonctionnelles du protocole et de formaliser un protocole de la vie réelle basé sur ladite fonctionnalité dans les sections ultérieures du document. Plus précisément, le protocole doit être capable de supporter les fonctionnalités suivantes :
1. procédure d'extraction de leader préservant la vie privée,
2. accès sans autorisation au mécanisme de consensus,
3. finalité transactionnelle quasi instantanée,
4. confidentialité transactionnelle,
5. fonction de transition d'état quasi-Turing-complet avec des capacités de vérification de preuve à connaissance nulle native.
Nous définissons un protocole abstrait idéalisé comme Pideal, instancié sous l'environnement E
ment E. Nous supposons qu'E est responsable de la gestion des communications avec les participants de Pideal. On suppose qu'E suit les règles du protocole, a un nombre illimité
ressources computationnelles et être 'omniscient' (c'est-à-dire qu'E a accès à l'état interne de chaque participant de Pideal).
Une interaction entre le participant au protocole et E est gérée via une demande-réponse
méthode de communication commune parmi la littérature des protocoles des systèmes distribués-
érature. Nous supposons que le canal de communication entre les participants au protocole-
pant i et E est sécurisé. Pour initier une demande, i doit communiquer un message Req
à E, qui, à son tour, répondrait par un message Res. Plus précisément, Pideal E
est instancié avec le support des types de messages Req et Res suivants :
1. ENREGISTRER, un type de message responsable de demander à E de créer un nouveau
paire de clés (sk, pk) et enregistrer un nouveau compte.
2. ENVOYER, un type de message responsable de demander à E d'envoyer un nombre défini-
du nombre de jetons natifs vers une clé publique définie pkr du récepteur.
3. CRÉER, un type de message responsable de demander à E de créer une appli- cation Application. Nous supposons que les applications peuvent avoir une fonctionnalité arbitraire et peuvent interagir les unes avec les autres, avec leur état accessible à tout participant au protocole, à l'exception des données liées à un ensemble de fonctionnalités spécifiques telles que les transferts d'actifs, le vote, les demandes de dividendes, etc.
4. APPEL, un type de message responsable de demander à E d'exécuter un appel à une application définie.
De plus, nous supposons que chaque demande est immédiatement exécutée par E, l'issue devenant irréversible dès que l'exécution est terminée.
Avec cela, nous avons défini un protocole abstrait capable de faciliter la fonctionnalité décrite au début de la section.
