Quelles sont les innovations de DFINITY ?

J'ai rencontré Mahnush, qui fait depuis longtemps partie de l'équipe DFINITY, pour discuter des différentes innovations que DFINITY publiera. Les sujets couvrent des termes tels que les signatures de seuil, les balises aléatoires et la génération de clés distribuées. Nous discutons non seulement de ces concepts, mais aussi de la raison pour laquelle ils sont si importants.
Bonjour et bienvenue dans un autre épisode de Inside DFINITY. Aujourd'hui, je vais parler à Mahnush, qui nous a rejoint très tôt en tant que chercheur. Elle vient de Yale, et aujourd'hui nous allons jeter un œil à ce qu'elle fait chez DFINITY, ce qu'elle a fait auparavant, puis elle va également nous donner un aperçu de certaines des technologies et innovations développées par DFINITY.
Merci, vous avez rejoint DFINITY très tôt. Vous avez été un élément clé de notre équipe de recherche depuis les premiers jours. Peut-être pour les gens qui n'ont pas encore entendu parler de vous : « Qu'est-ce que tu fais ici ?
Donc, je suis chercheur et ce que je fais, c'est aider et concevoir la couche consensus et prouver la sécurité de la couche consensus et des balises aléatoires.
Mon travail quotidien consiste à collecter les idées de l'équipe, à les rendre plus formelles afin que nous puissions les comprendre entre nous, à les rédiger formellement, puis j'aime prouver qu'elles sont sûres afin que nous puissions les utiliser.
Je pense qu'une bonne façon dont vous m'avez décrit hier est : "Je prends tout ce que nous proposons et je m'assure que c'est sûr." Je certifie que c'est sûr, pour ce que nous essayons de construire avec DFINITY. Quelque chose que je pense être un attribut très important.
Qu’est-ce qui vous a amené à ce poste ? Qu'avez-vous fait avant? D'où venez-vous?
Avant de rejoindre DFINITY, j'étais postdoctorant à l'Université de Yale. Avant cela, j’étais doctorant. Pour mon doctorat, j'ai travaillé sur la sécurité, comme le calcul multipartite.
Calcul multipartite sécurisé
Le calcul multipartite sécurisé est l'endroit où vous devez vous assurer que toutes les parties parviennent à un accord. Une partie importante de l’informatique est le résultat, sur lequel tout le monde devrait s’entendre. Par conséquent, le consensus et l’accord byzantin sont des éléments importants du protocole MPC. C'est pourquoi je m'intéresse aux protocoles de consensus.
Puis, alors que j'étais à Yale, j'ai essayé d'élaborer un protocole consensuel qui s'étendrait à des millions de partis en utilisant un protocole basé sur un comité. Ensuite, j'ai rencontré Timo et Dominic et j'ai appris que DFINITY essayait de faire la même chose, ce qui m'intéressait.
C'est super de t'avoir. Je sais que nous avons fait beaucoup de progrès depuis votre arrivée, y compris le livre blanc que nous avons publié au début de cette année, et je sais que vous avez passé de nombreuses nuits blanches à y travailler.
Cloud computing
Quelle énigme ou quelle question intéressante essayons-nous de résoudre ici ? Je pense que ce que nous essayons de faire chez DFINITY est une nouvelle version du cloud computing, qui, si vous y réfléchissez bien, est en réalité un réplicateur d'état.
Parce que vous devez avoir beaucoup de répliques pour vous assurer de ne pas perdre de calculs ou de données, mais toutes doivent avoir un accord. Parce que si certains d'entre eux pensent que quelque chose est définitif et que d'autres copies pensent que quelque chose d'autre est définitif, alors les utilisateurs ne sauront pas quelle version est correcte.
Par conséquent, garantir la cohérence de toutes ces copies est une partie très importante de DFINITY. C'est pourquoi les protocoles de consensus sont souvent très importants pour DFINITY.
Maintenant, si toutes les répliques sont honnêtes, alors c'est beaucoup plus facile car nous pouvons nous assurer que, par exemple, si dans Google Cloud, vous avez plusieurs répliques et que vous êtes sûr que toutes les répliques sont contrôlées par Google, alors... c'est vrai, Ainsi, comme ils sont tous contrôlés par Google, vous pouvez être sûr que chaque ordinateur peut appliquer le même algorithme.
C'est ce que vous dites : "Ils sont tous honnêtes !" Oui, c'est beaucoup plus facile pour eux puisqu'ils appartiennent tous à un groupe central, mais en même temps il faut faire confiance à Google pour s'assurer que l'algorithme qu'ils utilisent courir est honnête.
réplique
Cependant, chez DFINITY, nous voulons garantir que tout le monde dans le monde puisse en avoir une copie, plutôt que de supposer que toutes les copies appartiennent à DFINITY. Il s'agit donc d'une approche plus ouverte du cloud computing.
Les utilisateurs n'ont pas besoin de faire confiance à DFINITY, mais ils peuvent faire confiance aux protocoles exécutés par DFINITY. À un moment donné, ce sera également open source, n'est-ce pas ? Qu'est-ce que cela signifie que tout le monde peut voir le code et que tout le monde peut en avoir une copie ?
Fondamentalement, cela signifie que tout le monde peut devenir mineur dans notre système, alors que les mineurs sont toujours nécessaires dans DFINITY. Même s’ils ne résoudront pas le casse-tête de la preuve de travail, ils constituent la puissance de calcul distribuée sur DFINITY.
Ils aident aux calculs, ils aident à la maintenance des données et ils aident à la maintenance des calculs sur les données.
Protocole pratique de tolérance aux pannes byzantines
Si les répliques sont différentes, comme des ordinateurs sur des domaines différents, certaines d'entre elles peuvent être corrompues ou contradictoires. En informatique, nous l'appelons byzantin car il vient du problème des généraux byzantins.
Eh bien, résoudre ce problème est un problème très difficile qui persiste en informatique depuis 40 ans. Et tout le monde essaie d’améliorer la solution parce qu’il s’agit d’un problème tellement fondamental.
Si vous résolvez ce problème efficacement, vous en résoudrez également de nombreux. Aujourd’hui, différentes tentatives constituent de nouvelles façons de résoudre le problème.
Donc, quand vous dites que le problème existe depuis longtemps, une solution, à mon avis, est que si j'ai trois copies indépendantes, deux disant une chose et la troisième disant autre chose, je crois toujours la majorité. Que se passe-t-il réellement sur le réseau en ce moment ? Dans quelle mesure est-ce complètement différent ?
C'est la première réponse proposée par les informaticiens : si vous avez plusieurs copies, disons trois copies, alors vous ne pouvez pas obtenir la majorité. Ainsi, une fois que vous avez obtenu la majorité, chacun doit envoyer sa contribution à tout le monde et c'est comme un circuit avec une communication très approfondie.
Pourtant, si vous êtes d’accord sur un seul point similaire, la majorité peut fonctionner. Mais si vous êtes d’accord comme une corde, même des groupes honnêtes peuvent ne pas être d’accord. Une des solutions pour utiliser le protocole PBFT est donc de choisir un leader.
Protocole PBFT (Byzantine Fault Tolerance)
Que signifie PBFT ? C'est comme la tolérance aux pannes byzantine (BFT), ils l'appellent le « mauvais côté » ou « côté byzantin », et le P dans PBFT vient du côté pratique.
Dans ce protocole, les serveurs répliques élisent un leader, donc, tout comme dans le monde réel, si vous voulez parvenir à un accord, le meilleur moyen est d'élire un leader, puis le leader dit quoi faire ensuite, tout le monde le fait. la même chose et ils parviennent à un accord.
Ainsi, à l’instar du protocole PBFT, ils choisissent un leader et si le leader est honnête, il offrira la même valeur à tous les membres du réseau avant de pouvoir parvenir à un accord.
Mais le problème est que si le leader n’est pas honnête, alors ils ne peuvent pas parvenir à un consensus et le leader doit être remplacé. Vérifiez que le leader est honnête et offre la même valeur à tout le monde et c'est une affaire très coûteuse sans changer de leader (on appelle cela changer de perspective), donc cela nécessite une communication à tous les niveaux, ce qui coûte très cher.
Protocole blockchain
Ensuite, les protocoles blockchain apparaissent comme Bitcoin et ils décident de ne pas changer de leader tant qu'il est malhonnête, et ils décident, eh bien, non, nous devons réellement changer de leader uniquement si le leader est malhonnête. Nous supposons que le protocole est synchrone, nous changeons donc de leader à chaque nouvelle époque, à chaque nouveau cycle.
Ensuite, ils ont besoin d’un moyen de choisir un leader, car il faut choisir le leader, puis le prochain leader, et encore le prochain leader.
Vous n'avez pas besoin de vérifier continuellement si le leader est honnête, vous continuez simplement à vous baser sur le protocole, sur les journaux. Il y a de fortes chances que l’un de ces dirigeants parvienne à un accord honnête et sain. Le problème se réduit désormais à la sélection d'un leader qui nécessite des nombres aléatoires.
Parce que si vous avez un nombre aléatoire, comme un dé, vous pouvez alors utiliser ce nombre aléatoire pour choisir un leader, et c'est là que la preuve de travail (POW) est utile.
preuve de travail
À la base, les protocoles blockchain sont des protocoles byzantins car ils utilisent essentiellement une preuve de travail pour sélectionner les dirigeants. En exécutant simplement la preuve de travail, la première personne à proposer une solution de preuve de travail est le leader, ce qui est un processus aléatoire.
Alors quand je parle à des parents ou à d'autres personnes intéressées par la blockchain, et je le fais souvent, je leur demande : Comment sélectionner au hasard une des personnes dans cette salle, disons qu'il y a 10 personnes dans la salle ?
Premièrement, tout le monde pense que c'est facile, comme si nous lancions simplement des dés. Je pense. Alors, qui lance les dés ? Ils disent, nous additionnons simplement toutes les dates de naissance, en commençant par vous, puis nous entourons jusqu'à ce que nous atteignions ce nombre. Mais alors, comment choisir par qui commencer ?
Cela semble donc être une question très simple. Mais si vous voulez vraiment que ce soit aléatoire, c'est difficile. C’était la grande innovation de Bitcoin, trouver un moyen de se mettre d’accord sur des choix aléatoires entre pairs.
Essentiellement, utiliser la preuve de travail pour créer du hasard est un moyen très coûteux de créer du hasard car vous devez consommer beaucoup d’électricité.
Ainsi, pour les efforts actuels comme Bitcoin, c’est comme une nation puissante qui s’efforce de résoudre la preuve de travail, c’est pourquoi c’est intrinsèquement très coûteux.
En fait, nous n'utilisons pas beaucoup Bitcoin, et si vous vouliez utiliser Bitcoin pour de nombreuses tâches informatiques, vous devrez en graver le monde entier. Si nous comparons où en est Bitcoin aujourd’hui et où il doit aller pour réaliser la vision, vous devrez toujours utiliser Bitcoin dix ou cent fois.
Vous avez mentionné que cela consomme beaucoup d'énergie. Par conséquent, nous recherchons une méthode plus efficace de sélection des dirigeants afin de sélectionner des personnes aléatoires parmi leurs pairs.
Preuve de travail comme protocole de synchronisation
Une autre raison pour laquelle nous essayons de changer la façon dont Bitcoin crée le caractère aléatoire est que la preuve de travail est intrinsèquement un protocole synchrone, donc essentiellement le temps que vous devez consacrer à la preuve de travail est d'un ordre de grandeur supérieur à la latence du réseau.
Sinon, vous ne savez pas si les gens préfèrent brûler de l'électricité pour résoudre une preuve de travail ou passer du temps à résoudre une preuve de travail, ou si leurs informations sont perdues dans le réseau.
Essentiellement, les chaînes de preuve de travail ou le consensus de preuve de travail ont un faible débit et vous ne pouvez pas effectuer de ticks rapidement car vous devez essentiellement attendre plus longtemps que la latence du réseau pour que le prochain élément aléatoire soit créé.
C'est pourquoi vous ne pouvez pas ajouter un protocole à haut débit, et c'est pourquoi les transactions deviennent également très coûteuses, car seul un nombre limité de transactions peut tenir dans chaque bloc. Nous ne pouvons pas augmenter le nombre de blocs par unité de temps sans gâcher le protocole.
Comment DFINITY crée des nombres aléatoires
DFINITY essaie de résoudre ce problème, donc la première pensée est la suivante : maintenant nous avons besoin d’une nouvelle façon de créer du hasard, mais maintenant, comment pouvons-nous créer du hasard ?
Comme je l'ai dit, c'est une question très difficile. Une approche consiste donc à demander à une personne de créer le caractère aléatoire, mais si cette personne est malhonnête, elle ne peut pas biaiser le caractère aléatoire.
Maintenant, nous avons besoin d'un groupe pour créer le caractère aléatoire, mais si nous choisissons un groupe, alors si je suis la première personne à créer le caractère aléatoire et que vous êtes la deuxième personne, alors la dernière personne peut regarder notre nombre aléatoire et choisir le sien. aléatoire, le résultat est ce qu'il veut, nous appelons cela le biais du dernier homme.
Nous ne pouvons pas avoir un groupe où la dernière personne choisit le hasard, c'est pourquoi nous utilisons la cryptographie à seuil.
cryptographie à seuil
Ce que signifie la cryptographie à seuil, c'est qu'au lieu d'avoir un groupe de n personnes, mais que toutes les n personnes doivent créer du hasard, il existe un groupe de n personnes, mais seulement K d'entre elles doivent participer.
Si vous attendez K personnes, alors si vous recevez une contribution de K moins 1 participant, vous attendez une contribution. Mais n’importe quel autre parti avec n moins K peut être la dernière personne. Il n’y a donc pas de préjugé à la dernière personne.
Si la dernière personne décide « Je ne veux pas participer », alors il y a un autre parti, mais cela ne suffit pas. Car maintenant si les membres de ce groupe de K personnes génèrent du hasard, et que le comportement d'un autre groupe de K personnes génère du hasard, si ces deux hasards sont différents, l'adversaire (en déterminant si je veux participer à ce groupe) peut biaiser le protocole. C'est pourquoi nous avons besoin d'unicité.
unicité
Le caractère unique du caractère aléatoire signifie que peu importe quelle partie K participe à la création du caractère aléatoire, le résultat est toujours unique et le résultat est toujours le même. Tout d’abord, c’est une propriété incroyable. Aussi contre-intuitif que cela puisse paraître, « Comment y arriver ? »
Si vous avez un message et si vous utilisez les signatures BLS pour la signature de seuil, vous avez besoin de K participants. Si le seuil est K, vous avez besoin de K participants pour le signer, peu importe qui signent les k participants, vous obtiendrez alors un résultat d'identité unique. Il s’agit d’un attribut clé des signatures BLS.
Il s'agit d'une technologie de cryptage basée sur le couplage. C'est donc nouveau, mais pas trop nouveau, car si le système est trop nouveau, vous vous inquiétez de la sécurité et vous vous demandez s'il a été correctement prouvé. Si suffisamment de personnes l’examinent, laissez des commentaires et testez-le.
À Stanford, suffisamment de personnes l'ont examiné et le groupe a travaillé longtemps pour s'assurer qu'il était sécurisé et qu'il ressemblait à un protocole très sécurisé avec de bonnes implémentations autour. Nous avons donc une implémentation BLS très rapide, open source et tout le monde peut l'utiliser.
Peut-être, donnez-nous simplement un aperçu, et nous pourrons ensuite également parler des balises aléatoires et de ce qu'elles sont exactement. Mais vous l'avez mentionné, et je pense que c'est une bonne explication de par où commencer et où la preuve de travail ne dépasse pas un certain point en termes de débit et de consommation d'énergie.
Ensuite, le problème de l'utilisation du biais de la dernière personne pour créer ce nombre aléatoire, nous le résolvons par k à partir des signatures seuils de n personnes. Et la signature BLS que nous utilisons est unique à k personnes sur n personnes et est toujours aléatoire. Ce sont deux propriétés dont j’ai encore du mal à toujours voir comment elles s’articulent.
Alors, que devrions-nous faire? Revenons aux blockchains de Satoshi Nakamoto et voyons comment elles fonctionnent. Ainsi, la blockchain de Nakamoto revient à créer complètement du caractère aléatoire pour chaque bloc, ce qui signifie que pour chaque bloc, vous résolvez la preuve de travail depuis le début et vous ne réutilisez aucun élément aléatoire.
C'est une des raisons pour lesquelles c'est si cher. Nous ne voulons donc pas faire cela ici parce que nous savons que le chiffrement à seuil est très coûteux, tout comme dans le monde de la preuve de travail. Ce n'est pas si cher, mais ça reste une opération très coûteuse.
Nous voulons nous assurer que la plupart des opérations coûteuses peuvent être effectuées hors ligne, et lorsque nous sommes en ligne, nous en effectuons très peu. Si vous examinez le système de signature, vous constaterez que différentes méthodes doivent être traitées et qu’elles doivent fonctionner. L’une d’elles consiste donc à créer des clés, nous l’appelons Distributed Key Generation (DKG).
DKG (génération de clés distribuées)
DKG (Distributed Key Generation) est une opération très coûteuse car vous devez tout le monde se mettre d'accord sur la clé publique qu'ils souhaitent signer, et chacun génère une clé pour lui-même qui fait partie d'une clé plus grande pour le groupe afin qu'il puisse l'utiliser pour signer. saisir.
Tout le processus est un processus coûteux, vous devez utiliser une clé pour vous authentifier, c'est donc un processus coûteux. Juste pour une discussion rapide, je pense que c'est aussi un sujet intéressant, cela signifie essentiellement que nous sommes tous dehors, que nous nous parlons tous, mais que nous avons tous convenu d'une clé non publique.
C'est incroyable que nous puissions parler de cela... mais cela signifie également que nous avons tous les deux correctement créé la clé privée à utiliser avec cette clé publique, et même si nous n'avons mentionné notre clé privée à personne d'autre, toutes nos clés privées les clés fonctionnent également ensemble d’une manière ou d’une autre.
La bonne nouvelle est que vous pouvez exécuter le processus DKG une fois, puis signer plusieurs fois avec la même clé, ce qui signifie que vous devez amortir le coût du coûteux DKG sur plusieurs fois. Vous pouvez faire un tour et exécuter DKG sur un groupe, puis, une fois qu'ils auront leur propre clé, ils pourront l'utiliser pour signer différentes entrées.
Chaque fois qu'ils signent à nouveau, ils obtiennent un nouveau nombre aléatoire, c'est un nouveau nombre pseudo-aléatoire, en fait ce n'est plus un nombre aléatoire car le premier était aléatoire, mais après c'est une fonction pseudo-aléatoire. Il agit pour vous comme un nombre pseudo-aléatoire.
Ainsi, nous pouvons rendre le schéma de signature non interactif, ce qui signifie « Je n'ai pas besoin de vous parler pour signer ».
Je fais de mon mieux, je signe, vous faites votre part, vous signez, mais nous pouvons rassembler ces signatures et les fusionner et obtenir une signature fusionnée sans avoir à nous parler.
C'est ce qu'ils appellent non interactif. C'est une propriété intéressante car elle rend le schéma de signature beaucoup plus rapide que la version non interactive.
La façon dont DFINITY fonctionne est que nous créons le groupe, puis nous faisons le DKG, maintenant nous signons le premier hasard, puis nous obtenons un hasard pour ce tour, puis au tour suivant nous signons le hasard précédent pour le tour suivant Créer un nouveau tour du hasard et ensuite, on procède à la signature.
Combien de temps voulons-nous réutiliser le même hasard original ? Vous pouvez le réutiliser pendant une longue période, vous pouvez le réutiliser pendant quelques mois, voire environ un mois ou deux. Par conséquent, le même caractère aléatoire peut être réutilisé tant qu’il y a suffisamment de participants dans le groupe qui sont toujours actifs et honnêtes. Vous avez également parlé de groupes.
Existe-t-il différents groupes pour le fonctionnement de DFINITY ? Nous avons cette cryptographie à seuil, nous avons le processus DKG, mais si vous souhaitez exécuter ce processus sur un grand nombre de participants, comme 5 millions de Bitcoins, c'est un processus très coûteux car vous devez envoyer un message à tout le monde, chacun doit signer. .
Cela reste un processus très coûteux. Nous avons examiné le système et constaté que vous n'avez pas besoin de la signature de tout le monde, vous n'avez pas besoin de la participation de tout le monde au hasard. Vous pouvez vous livrer au hasard en sélectionnant les partis au hasard, tout comme on organise des élections dans un pays.
Donc, si vous voulez décider quelque chose qui n'oblige pas tout le monde à élaborer une loi ou à prendre une décision, vous pouvez avoir un comité, vous pouvez avoir des représentants au lieu de tout le monde, nous devrions choisir un groupe, mais comment choisir un groupe?
Nous pouvons néanmoins réutiliser notre propre caractère aléatoire, donc puisqu'un groupe est choisi au hasard, alors ce groupe a des propriétés similaires au nombre carré total réel. Au lieu d'exécuter l'intégralité du protocole auprès de 5 millions de personnes, vous pouvez l'exécuter auprès de 500 personnes et c'est dix fois plus rapide.
Qu'il y ait 100 000 personnes participant à l'ensemble du réseau ou 100 millions de personnes participant, le processus que traverse le groupe est toujours similaire car la taille du groupe est constante. Un autre avantage du choix des groupes est que vous obtenez non seulement l'évolutivité mais également le parallélisme, car nous pouvons désormais avoir plusieurs chaînes au lieu d'une seule.
Fragmentation
Chaque groupe est responsable d'une chaîne, vous pouvez alors créer plusieurs chaînes en parallèle, que nous appelons généralement fragments dans une blockchain. C'est une façon naturelle de fragmenter.
C'est pourquoi je pense que DFINITY a un excellent moyen de partitionnement qui est inhérent à DFINITY car nous avons des groupes et chaque groupe peut ensuite avoir son propre fragment. Alors, quels sont les plus gros problèmes auxquels nous sommes confrontés en ce moment ?
Actuellement, nous avons des épreuves complètes dans les paramètres de synchronisation. Dans le modèle de calcul synchrone ou de communication synchrone, lorsqu'une partie honnête envoie un message, il sera reçu par toutes les parties honnêtes dans la plage Delta.
Par exemple, dans Bitcoin, lorsqu’une partie honnête envoie un message, il sera reçu dans environ une minute, ce qui est moins d’une minute pour tout le monde dans le monde. Le protocole le sait et l'utilise.
Donc dans Bitcoin la durée de la preuve de travail dépend de la latence du réseau et elle devrait être beaucoup plus longue donc environ 10 minutes pour Bitcoin car ils pensent que Bitcoin est 10 fois plus long.
L'hypothèse de synchronisation est valable, mais le problème est que si l'hypothèse de synchronisation est incorrecte dans un réseau réel, le protocole n'est plus sécurisé.
Preuves complètes dans les réseaux asynchrones
Ce que nous avons fait dans DFINITY, c'est que nous disposons de preuves de sécurité dans un modèle entièrement synchrone, et nous mettons à jour nos preuves pour les rendre également utilisables sur les réseaux asynchrones.
C'est l'un des domaines sur lesquels je travaille en ce moment et l'autre domaine sur lequel je travaille est le processus interactif DKG que nous avons actuellement dans le processus DKG, ce qui signifie que chaque participant qui souhaite participer l'activité gère le DKG. Il devrait être possible d'utiliser DKG lors de la conclusion de l'accord.
DKG non interactif (génération de clés distribuées)
Nous voulons le rendre non interactif, ce qui signifie que les parties peuvent participer et revenir et revenir une fois l'accord terminé. C'est donc une façon plus naturelle de l'exécuter, DKG est la version non interactive plutôt que la version interactive.
La troisième chose sur laquelle je travaille est la partie sharding, dont je viens de parler. Nous concevons un système de partitionnement pour DFINITY. Nous avons conçu un système de partitionnement pour un réseau de type Bitcoin et nous utilisons le même concept et notre article sera publié sur CCS. C'est un bon article, vous devriez donc le lire.
Peut-être juste pour répondre à la question : « Quelles sont les exigences pour DFINITY ? Combien de personnes peuvent être malhonnêtes et le réseau peut encore survivre ? » C'est une bonne question.
Généralement, si vous travaillez dans un environnement asynchrone ou semi-synchrone, le nombre de parties qu'un protocole peut tolérer est d'un tiers. Ainsi, la fraction des partis malhonnêtes est toujours d’un tiers dans le modèle asynchrone, qui est la limite inférieure, donc il ne peut tolérer rien de plus élevé que cela.
Le système de partitionnement de DFINTY
DFINITY fonctionne selon ce modèle, ce qui signifie que la proportion de partis malhonnêtes dans l'ensemble du réseau devrait être d'un tiers, mais dans chaque groupe nous ne pouvons tolérer que la moitié de la proportion, donc nous passons d'un tiers à la moitié. « Savons-nous déjà quelle sera la taille de ces groupes ?
La taille du groupe dépend du niveau de sécurité que vous souhaitez atteindre : plus le groupe est grand, meilleure est la sécurité que vous gagnez. Actuellement, pour un niveau de sécurité d'environ 86 à 90, une taille définie entre 400 et 800 semble logique, ce qui signifie que la probabilité d'erreur serait d'environ 86. Vous ne perdez jamais vos jetons.
Temps de blocage et finalité
Une autre question avant de conclure est que nous avons parlé de l'efficacité énergétique et mentionné certains des temps de blocage de la blockchain Bitcoin, qui, comme vous l'avez mentionné, sont d'environ dix minutes. Alors, quel est le temps de blocage que nous atteignons dans DFINITY ?
Actuellement, sur notre réseau de test, les temps de blocage sont d'environ une seconde, soit moins d'une seconde.
Une autre différence entre DFINITY et Bitcoin est que pour atteindre la finalité avec Bitcoin, puisqu'ils n'ont pas de véritable protocole de consensus, vous devez attendre six blocs. Pour DFINITY, nous avons besoin de deux blocs.
Cela signifie donc 2 secondes, 1 seconde par bloc, 2 secondes de finalité, ce qui signifie que nous avons 2 secondes de finalité, alors que la finalité du Bitcoin est d'environ 1 heure.
En gros, c'est ce qui se passe sur DFINITY avec Bitcoin pour permettre une transaction de type carte de crédit et terminer la transaction, si je vais dans un café pour acheter un café, dans le pire des cas, je dois attendre une heure avant de pouvoir l'utiliser. mon Bitcoin. Assurez-vous que la transaction se déroule réellement, ce qui peut prendre jusqu'à deux secondes sur DFINITY.
Dans le meilleur des cas, si le fabricant de blocs est optimiste et honnête, il suffit d'attendre deux secondes pour que l'état final soit atteint dans DFINITY, alors c'est comme un système à haut débit.
Merci à Mahnush d'avoir pris le temps de nous expliquer certains des défis et innovations de DFINITY.
Contenu IC qui vous intéresse
Progrès technologique | Informations sur le projet |
Collectez et suivez IC Binance Channel
Restez à jour avec les dernières informations