Recherche Bitlayer : analyse des principes du DLC et réflexions sur l'optimisation

Titre original : “Bitlayer Core Technology : DLC et ses considérations d’optimisation”

Auteur original : lynndell & mutourend, Bitlayer Research Group

1. Introduction

Discreet Log Contract (DLC) est un ensemble de solutions d’exécution de contrats basées sur Oracle proposées par Tadge Dryja du MIT en 2018. Le DLC permet à deux parties d’effectuer des paiements conditionnels basés sur des conditions prédéfinies. Chaque partie détermine et pré-signe les résultats possibles, et utilise ces pré-signatures pour exécuter le paiement lorsqu’un oracle signe les résultats. En conséquence, le DLC permet de nouvelles applications financières décentralisées tout en assurant la sécurité des dépôts Bitcoin.

Par rapport au Lightning Network, le DLC présente les avantages significatifs suivants :

• Confidentialité : Le DLC est supérieur au Lightning Network en termes de protection de la vie privée. Les détails du contrat ne sont partagés qu’entre les participants et ne seront pas stockés sur la blockchain. En revanche, les transactions Lightning Network sont acheminées via des canaux et des nœuds publics, et leurs informations sont publiques et transparentes ;
• **Complexité et flexibilité des contrats financiers : **DLC peut créer et exécuter des contrats financiers complexes, tels que des produits dérivés, des assurances et des paris, directement sur le réseau Bitcoin, tandis que le réseau Lightning est principalement utilisé pour des transactions rapides et de petit montant. ne peut pas prendre en charge des applications complexes ;
• **Risque de contrepartie réduit : **Les fonds DLC sont bloqués dans des contrats multi-signatures et ne seront libérés que lorsque les résultats d’événements prédéfinis se produiront, réduisant ainsi le risque que l’une ou l’autre des parties ne respecte pas le contrat. Bien que le Lightning Network réduise le besoin de confiance, il existe toujours un certain risque de contrepartie en termes de gestion des canaux et de fourniture de liquidités ;
• **Pas besoin de gérer les canaux de paiement : **Les opérations DLC ne nécessitent pas la création ou la maintenance de canaux de paiement, qui sont un composant essentiel du Lightning Network. La gestion des canaux est complexe et gourmande en ressources ;
• Évolutivité pour des cas d’utilisation spécifiques : Le Lightning Network améliore dans une certaine mesure le débit des transactions de Bitcoin, tandis que le DLC offre une meilleure évolutivité en termes de contrats complexes sur Bitcoin.

Bien que le DLC présente de grands avantages dans les applications écologiques Bitcoin, il existe néanmoins certains risques et problèmes, tels que :

• Risque clé : La clé privée de l’oracle et le nombre aléatoire promis risquent d’être divulgués ou perdus, entraînant la perte des actifs de l’utilisateur ;
• **Risque de confiance centralisé : **Un problème de centralisation d’Oracle peut facilement conduire à des attaques par déni de service ;
• **Décentralisé sans dérivation de clé : ** Si l’oracle est décentralisé, le nœud oracle ne possède que le fragment de clé privée. Cependant, les nœuds Oracle décentralisés ne peuvent pas utiliser directement BIP 32 pour la dérivation de clé basée sur le partage de clé privée ;
• Risque de collusion : Si les nœuds oracle sont de connivence entre eux ou avec les parties participantes, le problème de confiance de la machine oracle n’est toujours pas résolu. Un mécanisme de supervision fiable est nécessaire pour minimiser la confiance dans les oracles ;
• Problème de changement de dénomination résolu : Les signatures conditionnelles nécessitent un ensemble déterministe d’événements énumérables avant de créer un contrat pour créer une transaction. Par conséquent, le DLC aura une limite de montant minimum pour la redistribution des actifs, ce qui entraînera un problème de changement de dénomination fixe.

A cet effet, cet article propose quelques solutions et idées d’optimisation pour résoudre les risques et problèmes des DLC et améliorer la sécurité de l’écosystème Bitcoin.

2.Principe du DLC

Alice et Bob signent un accord de pari : parier que la valeur de hachage du n+kème bloc est un nombre impair ou pair. S’il s’agit d’un nombre impair, Alice gagne la partie et peut retirer l’actif dans un délai t ; s’il s’agit d’un nombre pair, Bob gagne la partie et peut retirer l’actif dans un délai t. À l’aide du DLC, les n+kièmes informations de bloc sont transmises via l’oracle pour construire une signature conditionnelle afin que le bon gagnant remporte tous les actifs.

Initialisation : Le générateur de courbe elliptique est G et l’ordre est q.

Génération de clés : L’oracle, Alice et Bob génèrent indépendamment leurs propres clés privées et publiques.

• La clé privée de la machine oracle est z, la clé publique est Z et la relation Z=z⋅G est satisfaite ;
• La clé privée d’Alice est x et la clé publique est X, satisfaisant la relation X=x⋅G ;
• La clé privée de Bob est y, et sa clé publique est Y, satisfaisant la relation Y=y⋅G.

**Transaction en capital : **Alice et Bob créent ensemble une transaction de financement, chacun verrouillant 1 BTC dans une sortie multi-signature 2 sur 2 (une clé publique X appartient à Alice et une clé publique Y appartient à Bob).

**Transaction d’exécution de contrat :**Alice et Bob créent deux transactions d’exécution de contrat (Contract ution Transaction, CET) pour dépenser des transactions d’injection de capital.

Engagements d’Oracle Computes

Ensuite, calculez S et S’

diffusion(R, S, S’).

Alice et Bob calculent chacun la nouvelle clé publique correspondante

Règlement : Lorsque le n+kème bloc apparaît, la machine Oracle génère les s ou s’ correspondants en fonction de la valeur de hachage du bloc.

• Si la valeur de hachage du bloc n+k est impaire, l’oracle calcule et diffuse s

• Si la valeur de hachage du bloc n+k est paire, l’oracle calcule et diffuse s’

Retrait : L’un des participants, Alice ou Bob, peut retirer des actifs en fonction des s ou des s diffusés par l’oracle.

• Si l’oracle diffuse s, Alice peut calculer la nouvelle clé privée sk^{Alice} et retirer les 2 BTC verrouillés

• Si l’oracle diffuse s’, Bob peut calculer la nouvelle clé privée sk^{Bob} et retirer les 2 BTC verrouillés

Analyse : La nouvelle clé privée sk^{Alice} calculée par Alice et la nouvelle clé publique PK^{Alice} satisfont la relation logarithmique discrète

Dans ce cas, le retrait de devises d’Alice réussira.

De la même manière, la nouvelle clé privée sk^{Bob} calculée par Bob et la nouvelle clé publique PK^{Bob} satisfont la relation logarithmique discrète

Dans ce cas, le retrait de Bob réussira.

De plus, si l’oracle diffuse des s, cela est utile à Alice mais pas à Bob. Parce que Bob ne peut pas être utilisé pour calculer la nouvelle clé privée correspondante sk^{Bob}. De la même manière, si l’oracle diffuse des s’, cela sert à Bob, mais pas à Alice. Parce qu’Alice ne peut pas être utilisée pour calculer la nouvelle clé privée correspondante sk^{Alice}.

Enfin, la description ci-dessus omet les verrous temporels. Un verrou temporel doit être ajouté afin qu’une partie puisse calculer la nouvelle clé privée et retirer la devise dans un délai t. Sinon, si le temps t est dépassé, l’autre partie peut retirer les actifs en utilisant la clé privée d’origine.

3.Optimisation des DLC

3.1 Gestion des clés

Dans le protocole DLC, la clé privée de l’oracle et le nombre aléatoire promis sont cruciaux. Si la clé privée de l’oracle et le nombre aléatoire promis sont divulgués ou perdus, cela entraînera facilement les quatre problèmes de sécurité suivants :

(1) La machine Oracle perd la clé privée z

Si l’oracle perd la clé privée, le DLC ne peut pas être réglé, ce qui nécessite d’exécuter le contrat de remboursement du DLC. Une transaction de remboursement est donc mise en place dans le protocole DLC pour éviter que l’oracle ne perde sa clé privée.

(2) La machine Oracle divulgue la clé privée

Si la clé privée de l’oracle est divulguée, tous les DLC basés sur la clé privée seront confrontés au risque de règlement frauduleux. Un attaquant qui vole la clé privée peut signer n’importe quel message de son choix, obtenant ainsi un contrôle total sur le résultat de tous les futurs contrats. De plus, l’attaquant ne se limite pas à publier un seul message signé, mais peut également publier des messages contradictoires, comme la signature du n+kème bloc avec des hachages pairs et impairs en même temps.

(3) La machine Oracle divulgue ou réutilise le nombre aléatoire k

Si l’oracle divulgue le nombre aléatoire k, alors pendant la phase de règlement, que l’oracle diffuse s ou s’, l’attaquant peut calculer la clé privée z de l’oracle comme suit

Si la machine oracle réutilise le nombre aléatoire k, alors après deux règlements, l’attaquant peut résoudre le système d’équations selon la signature diffusée par la machine oracle et l’une des quatre situations suivantes pour obtenir la clé privée z de la machine oracle,

Cas 1:

Cas 2 :

Cas 3 :

Cas 4 :

(4) La machine Oracle perd le nombre aléatoire k

Si l’oracle perd le nombre aléatoire k, le DLC correspondant ne pourra pas être réglé et le contrat de remboursement du DLC devra être exécuté.

Par conséquent, afin d’améliorer la sécurité de la clé privée Oracle, le BIP 32 doit être utilisé pour dériver la clé enfant ou la clé petit-enfant pour la signature. De plus, pour améliorer la sécurité du nombre aléatoire, la valeur de hachage k:=hash(z, counter) de la clé privée et du compteur doit être utilisée comme nombre aléatoire k pour éviter que le nombre aléatoire ne soit répété ou perdu.

3.2 Oracle décentralisé

Dans le DLC, l’oracle joue un rôle essentiel, en fournissant des données externes clés qui déterminent l’issue du contrat. Pour améliorer la sécurité de ces contrats, des oracles décentralisés sont nécessaires. Contrairement aux oracles centralisés, les oracles décentralisés répartissent la responsabilité de fournir des données précises et inviolables sur plusieurs nœuds indépendants, ce qui peut réduire le risque de s’appuyer sur un point de défaillance unique et réduire la possibilité de manipulation ou d’attaques ciblées. Grâce à des oracles décentralisés, DLC peut atteindre un degré plus élevé de manque de confiance et de fiabilité, garantissant que l’exécution du contrat repose entièrement sur l’objectivité de conditions prédéterminées.

Les signatures de seuil Schnorr permettent des oracles décentralisés. La signature de seuil de Schnorr présente les avantages suivants :

• **Sécurité améliorée : **Grâce à la gestion des clés décentralisées, les signatures à seuil réduisent le risque de points de défaillance uniques. Même si les clés de certains participants sont divulguées ou attaquées, l’ensemble du système reste sécurisé tant que le seuil fixé n’est pas dépassé.
• **Contrôle distribué : **La signature à seuil réalise un contrôle distribué de la gestion des clés. Aucune entité ne dispose de tout le pouvoir de signature, réduisant ainsi le risque causé par une concentration excessive du pouvoir.
• Améliorer la disponibilité : Seul un certain nombre de nœuds Oracle doivent accepter pour compléter la signature, ce qui améliore la flexibilité et la disponibilité du système. Même si certains nœuds ne sont pas disponibles, cela n’affectera pas le fonctionnement fiable de l’ensemble du système.
• Flexibilité et évolutivité : Le protocole de signature de seuil peut définir différents seuils selon les besoins pour s’adapter à diverses exigences et scénarios de sécurité. De plus, il convient également aux réseaux à grande échelle et présente une bonne évolutivité.
• Responsabilité : Chaque nœud Oracle génère des fragments de signature pour les messages basés sur des fragments de clé privée. D’autres participants peuvent utiliser les fragments de clé publique correspondants pour vérifier l’exactitude des fragments de signature afin d’assurer la traçabilité. Si cela est correct, les fragments de signature sont accumulés pour générer une signature complète.

Par conséquent, le protocole de signature à seuil Schnorr présente des avantages significatifs dans les oracles décentralisés qui améliorent la sécurité, la fiabilité, la flexibilité, l’évolutivité et la responsabilité.

3.3 Couplage décentralisation et gestion des clés

Dans la technologie de gestion des clés, la machine Oracle dispose d’une clé complète z, basée sur la clé complète z et l’incrément ω, en utilisant BIP 32, elle peut envoyer un grand nombre de sous-clés z+{ω }^{(1) } et la clé secrète du Soleil z+ω ^{( 1)}+ω ^{( 2)}. Pour différents événements, l’oracle peut utiliser différentes clés privées de petits-enfants z+ω ^{(1)}+ω ^{(2)} pour générer la signature correspondante σ pour le message d’événement correspondant.

Dans le scénario d’application Oracle décentralisée, il y a n participants et t+1 participants sont requis pour effectuer des signatures de seuil. Parmi eux, t. n nœuds Oracle ont chacun un fragment de clé privée z_i, i= 1,…, n. Ces n fragments de clé privée z_i correspondent à une clé privée complète z, mais la clé privée complète z n’apparaît pas du début à la fin. En partant du principe que la clé privée complète z n’apparaît pas, t+ 1 nœuds oracle utilisent des fragments de clé privée z_i, i= 1,…, t+ 1 pour générer des fragments de signature σ_i’ pour le message msg’, et la signature Les fragments σ_i’ sont fusionnés dans la signature complète σ’. Le vérificateur peut vérifier l’exactitude de la paire de signatures de message (msg’,σ ') en utilisant la clé publique complète Z. Étant donné que t+1 nœuds Oracle sont nécessaires pour générer conjointement une signature de seuil, celle-ci est hautement sécurisée.

Cependant, dans le scénario d’application Oracle décentralisée, la clé privée complète z n’apparaît pas et le BIP 32 ne peut pas être utilisé directement pour la dérivation de clé. En d’autres termes, la technologie de décentralisation Oracle et la technologie de gestion des clés ne peuvent pas être directement couplées.

L’article Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets** propose une méthode de dérivation de clé distribuée dans le scénario de signature à seuil. ** L’idée centrale de cet article est que selon le polynôme d’interpolation lagrangien, le fragment de clé privée z_i et la clé privée complète z satisfont à la relation d’interpolation suivante

En ajoutant l’incrément ω aux deux côtés de l’équation ci-dessus, nous obtenons l’équation suivante

Cette équation montre que : le fragment de clé privée z_i plus l’incrément ω satisfait toujours la relation d’interpolation avec la clé privée complète z plus l’incrément ω. En d’autres termes, le fragment de clé sous-privée z_i+ω et la sous-clé z+ω satisfont la relation d’interpolation. Par conséquent, chaque participant peut utiliser le fragment de clé privée z_i plus l’incrément ω pour dériver le fragment de clé sous-privée z_i+ω, qui est utilisé pour générer le fragment de sous-signature, et utiliser la clé sous-publique correspondante. Z+ω ⋅G peut effectuer une vérification de validité.

Il convient toutefois de considérer la différence entre les BIP améliorés et non améliorés 32 . Le BIP 32 amélioré prend la clé privée, le code de chaîne et le chemin en entrée, calcule SHA 512 et génère l’incrément et le code de sous-chaîne. Le BIP 32 non amélioré prend la clé publique, le code de chaîne et le chemin en entrée, calcule SHA 512 et génère l’incrément et le code de sous-chaîne. Dans le cas d’une signature à seuil, la clé privée n’existe pas, donc seul le BIP 32 non amélioré peut être utilisé. Ou utilisez des fonctions de hachage homomorphes, il existe un BIP 32 amélioré. Cependant, la fonction de hachage homomorphe est différente de SHA 512 et est incompatible avec le BIP 32 d’origine.

3.4 OP-DLC : minimiser la confiance dans Oracle

Dans le DLC, le contrat entre Alice et Bob est exécuté sur la base du résultat de la signature de l’oracle, il faut donc faire confiance à l’oracle dans une certaine mesure. Par conséquent, le comportement correct de la machine Oracle est une condition préalable majeure au fonctionnement du DLC.

Pour se méfier des oracles, il y a eu des études sur l’exécution de DLC basées sur les résultats de n oracles pour réduire la dépendance à un seul oracle.

• Le modèle « n-of-n » signifie utiliser n oracles pour signer un contrat et exécuter le contrat sur la base des résultats des n oracles. Ce modèle nécessite n oracles pour que tous signent en ligne. Si un oracle se déconnecte ou a des désaccords sur les résultats, cela affectera l’exécution du contrat DLC. L’hypothèse de confiance est que tous les oracles sont honnêtes.
• Le modèle « k-of-n » signifie utiliser n oracles pour signer un contrat et exécuter le contrat sur la base des résultats de k oracles. Si plus de k oracles s’entendent, cela affectera la bonne exécution du contrat. De plus, lors de l’utilisation du modèle « k-of-n », le nombre de CET qui doivent être préparés est C_n^k fois celui d’un seul oracle ou du modèle « n-of-n ». L’hypothèse de confiance est qu’au moins k des n oracles sont honnêtes.

Augmenter le nombre de machines Oracle n’entraîne pas la méfiance à l’égard des machines Oracle. Parce que lorsque l’oracle fait quelque chose de mal, la partie lésée dans le contrat n’a pas de voie de recours sur la chaîne.

**Par conséquent, cette section propose OP-DLC, qui introduit le mécanisme de défi optimiste dans le DLC. Avant de participer à la configuration du DLC, **n oracles doivent s’engager à l’avance à construire le jeu OP sur la chaîne sans autorisation et promettre de ne pas faire le mal. Si un oracle agit mal, Alice ou Bob, ou tout autre oracle honnête ou autre observateur tiers honnête, peut lancer un défi. Si le challenger remporte la partie, l’oracle maléfique sera puni sur la chaîne et son dépôt sera perdu. De plus, OP-DLC peut également être signé en utilisant le modèle « k-of-n ». Parmi eux, la valeur de k peut même être 1. Par conséquent, l’hypothèse de confiance est réduite à ce que tant qu’il y a un participant honnête dans le réseau, un défi OP peut être lancé pour punir le nœud oracle maléfique.

Lors du règlement de l’OP-DLC sur la base des résultats du calcul de la couche 2 :

• Si l’oracle utilise une signature de résultat incorrecte, ce qui porte atteinte aux intérêts d’Alice, Alice peut utiliser la couche 2 pour calculer correctement le résultat et contester le jeu OP sur la chaîne sans autorisation où l’oracle s’est engagé à l’avance. Alice gagne la partie, punit l’oracle maléfique et compense la perte ;
• De la même manière, Bob, d’autres nœuds Oracle honnêtes et des observateurs tiers honnêtes peuvent tous lancer des défis. Cependant, pour éviter les défis malveillants, le challenger doit également miser.

Par conséquent, OP-DLC permet aux nœuds Oracle de se superviser les uns les autres, minimisant ainsi la confiance dans Oracle. Ce mécanisme ne nécessite qu’un seul participant honnête et a un taux de tolérance aux pannes de 99 %, ce qui résout mieux le risque de collusion entre les machines Oracle.

3.5 OP-DLC + double pont BitVM

Lorsque le DLC est utilisé comme pont entre chaînes, une allocation de fonds est requise lors du règlement du contrat DLC :

• Nécessite une pré-configuration via CET. Cela signifie que la granularité de règlement des fonds du DLC est limitée, comme la granularité du réseau Bison de 0,1 BTC. Il y a un problème : les interactions entre les actifs des utilisateurs au niveau 2 ne doivent pas être limitées à la granularité des fonds du DLC CET.
• Lorsqu’Alice souhaite régler ses actifs de couche 2, les actifs de couche 2 de l’utilisateur Bob seront également forcés d’être réglés sur la couche 1. Il y a un problème : chaque utilisateur de couche 2 devrait pouvoir choisir librement de déposer et de retirer des fonds sans être affecté par les dépôts et retraits des autres utilisateurs.
• Alice et Bob négocient le coût. Il y a un problème : les deux parties doivent être disposées à coopérer.

**Par conséquent, afin de résoudre les problèmes ci-dessus, cette section propose un double pont OP-DLC + BitVM. Cette solution permet aux utilisateurs de déposer et de retirer de l’argent via le pont sans autorisation de BitVM, ainsi que de déposer et de retirer de l’argent via le mécanisme OP-DLC, permettant ainsi d’obtenir des changements à n’importe quelle granularité et d’améliorer la liquidité du capital. **

Dans OP-DLC, l’oracle est la BitVM Alliance, Alice est un utilisateur ordinaire et Bob est la BitVM Alliance. Lors de la configuration de l’OP-DLC, dans le CET construit, la sortie destinée à l’utilisateur Alice peut être dépensée immédiatement sur la couche 1, et dans la sortie destinée à Bob, un “jeu DLC auquel Alice peut participer au défi” est construit et un verrouillage temporel période est fixée. Quand Alice veut retirer de l’argent :

• Si BitVM Alliance agit comme un oracle et signe correctement, Alice peut retirer de l’argent au niveau 1. Cependant, Bob peut retirer de l’argent sur la couche 1 après avoir attendu l’expiration de la période de blocage.
• Si l’Alliance BitVM agit comme un oracle et triche, les intérêts d’Alice seront endommagés. Cependant, Alice peut défier l’UTXO de Bob. Si le défi réussit, le montant de Bob peut être confisqué. Remarque : L’un des autres membres de BitVM Alliance peut également lancer un défi, mais Alice est plus motivée à lancer un défi car ses intérêts sont lésés.
• Si l’Alliance BitVM agit comme un oracle et triche, les intérêts de Bob seront endommagés. Cependant, un membre honnête de l’Alliance BitVM peut défier le “Jeu BitVM” et punir les nœuds Oracle tricheurs.

De plus, lorsque l’utilisateur Alice souhaite retirer des fonds de la couche 2, mais que le CET prédéfini dans le contrat OP-DLC ne correspond pas au montant, Alice peut choisir les méthodes suivantes :

*Le retrait via BitVM est avancé par l’opérateur BitVM sur la couche 1. Le pont BitVM suppose un participant honnête à l’alliance BitVM.

• Retirez de l’argent via un certain CET dans OP-DLC, et le changement restant sera avancé par l’opérateur BitVM dans la couche 1. Le retrait OP-DLC fermera le canal DLC, mais les fonds restants du canal DLC seront transférés vers le pool de fonds BitVM Layer 1 sans obliger les autres utilisateurs de couche 2 à retirer des fonds. La confiance du pont OP-DLC suppose qu’il y a un participant honnête dans le canal.
• Alice et Bob négocient le coût sans la participation de la machine oracle, nécessitant la coopération de Bob.

Par conséquent, le double pont OP-DLC + BitVM présente les avantages suivants :

• Utilisez BitVM pour résoudre le problème de changement de fonds du canal DLC, réduire le nombre de paramètres CET et ne pas être affecté par la granularité du fonds CET ;
• Combinez le pont OP-DLC et le pont BitVM pour fournir aux utilisateurs plusieurs canaux de retrait et de dépôt et des modifications à n’importe quelle granularité ;
• Définissez l’alliance BitVM sur Bob et l’oracle, et minimisez la confiance de l’oracle via le mécanisme OP ;
• Introduisez le solde de retrait du canal DLC dans le pool de fonds relais BitVM pour améliorer l’utilisation des fonds.

4. Conclusion

Le DLC est apparu avant l’activation de Segwit v1 (Taproot), et l’intégration du canal DLC et du Lightning Network a été mise en œuvre, et le DLC a été étendu pour mettre à jour et exécuter des contrats continus au sein du même canal DLC. Avec l’aide de technologies telles que Taproot et BitVM, une vérification et un règlement de contrats hors chaîne plus complexes peuvent être réalisés au sein du DLC, tandis qu’en combinaison avec le mécanisme de défi OP, il est possible de minimiser la confiance d’Oracle.

les références

1. Spécifications pour les contrats de journaux discrets
2. Contrats de journaux discrets
3. Mise à l’échelle du DLC Partie 1 : Contrats de journaux discrets hors chaîne
4. Mise à l’échelle du DLC, partie 2 : problème d’option gratuite avec le DLC
5. Mise à l’échelle du DLC, partie 3 : Comment éviter les problèmes d’option gratuite avec le DLC
6. Réseau Lightning
7. DLC sur Lightning
8. Gestion des clés privées DLC, partie 1
9. Gestion des clés privées DLC Partie 2 : Les clés privées d’Oracle
10. Gestion des clés DLC Pt 3 : Distribution des clés publiques Oracle
11. BitVM : calculez n’importe quoi sur Bitcoin
12. BitVM 2 : vérification sans autorisation sur Bitcoin
13. Contrats Bitcoin hors chaîne BitVM
14. PIF 32 PIF 44
15. Signature Schnorr
16. FROST : Signatures de seuil de Schnorr flexibles et optimisées
17. Une enquête sur la signature du seuil ECDSA
18. Dérivation de clé distribuée pour la gestion multipartite des actifs numériques Blockchain
19. Témoin séparé
20. Cumul optimiste
21. Racine pivotante

Lien d’origine