[blockchain Learning column] - - consensus Algorithm

Zhangtuo2018 2022-01-14 16:03:21 阅读数:547

blockchain learning column consensus algorithm

Algorithme de consensus

1 Introduction à l'algorithme consensuel

L'algorithme consensuel fait référence à un scénario distribué,Un algorithme distribué exécuté par plusieurs noeuds pour obtenir le même état de données. Dans un scénario distribué,Perte possible de paquets réseau、Dérive de l'horloge、Arrêt du noeud、Les noeuds font du mal et d'autres défauts,L'algorithme consensuel doit être capable de tolérer ces erreurs,Assurez - vous que plusieurs noeuds obtiennent le même état de données.

Selon le type de défaut tolérable,Les algorithmes consensuels peuvent être divisés en deux catégories:

  • Algorithme de classe d'erreur tolérant les temps d'arrêt(crash fault tolerant consensus algorithm),Peut tolérer la perte de paquets réseau、Dérive de l'horloge、Certains noeuds s'arrêtent ce noeud est une erreur bénigne.Les algorithmes courants sont: Paxos、Raft.
  • Tolérance aux algorithmes byzantins de classe d'erreur(byzantine fault tolerant consensus algorithm),Certains noeuds peuvent tolérer n'importe quel type d'erreur,Y compris les noeuds qui font le mal.Les algorithmes courants sont: PBFT、PoW、PoSAttendez..

Selon le scénario d'utilisation,L'algorithme de consensus peut également être divisé en Consensus de chaîne publique、Consensus sur la chaîne de l'Alliance deux catégories.

1.1. Consensus sur la chaîne publique

La chaîne commune est caractérisée par un grand nombre de noeuds et une distribution dispersée des noeuds,Les principaux algorithmes consensuels utilisés sontPoWEtPoS,L'avantage de ces deux types de consensus est le grand nombre de noeuds qui peuvent être pris en charge,L'inconvénient estTPSFaible et long délai de confirmation de la transaction.

1.2. Consensus sur la chaîne de l'Alliance

La caractéristique de la chaîne de l'Alliance est que le réseau entre les noeuds est relativement stable et que les noeuds ont des exigences d'accès. , Vous pouvez choisir le type d'erreur que vous souhaitez tolérer RaftEtPBFTAlgorithme de classe, Les avantages de ces algorithmes sont: TPS Plus élevé et les transactions peuvent être confirmées en millisecondes , L'inconvénient est le nombre limité de noeuds pris en charge ,Normalement pas plus que100Noeuds.

2 Algorithme de consensus de la chaîne fédérée

2.1 Raft

Références:

2.1.1. Introduction à l'algorithme

RaftAlgorithmes C'est l'algorithme de consensus de classe tolérant les défauts non byzantins le plus largement utilisé . Raft L'algorithme repose principalement sur Mécanisme de voteEt Copie du Journal Mécanismes permettant de parvenir à un consensus entre les noeuds . Les noeuds Votent pour un leader,Parleader Responsable du traitement de toutes les demandes , Copier la requête dans un autre noeud sous forme de journal .

Raft Garanti dans un N Dans un système composé de noeuds (N+1)/2(Arrondi vers le Haut) Cohérence du système avec les noeuds fonctionnant correctement ,Comme dans un5 Autorisé dans le système pour les noeuds 2 Erreur non byzantine sur les noeuds ,Par exemple:Arrêt du noeudPartition du réseau Délai de message .RaftPar rapport àPaxosPlus facile à comprendre, Et s'est avéré capable de fournir Paxos Même tolérance aux défauts et même performance , Sa description détaillée est visible Site officielEtDémonstration dynamique.

2.1.2. Utilisation de l'algorithme

  1. Environnement Multi - noeuds sans prise en compte des noeuds malveillants ;
  2. Besoin de soutien élevé TPSL'environnement de.

2.1.3. Interprétation des termes

2.1.3.1 Type de noeud

InRaftDans l'algorithme, Chaque noeud réseau ne peut avoir qu'une des trois identités suivantes: :Leader、FollowerEtCandidate,Parmi eux:

  • Leader: Responsable de l'interaction avec le monde extérieur ,ParFollower Les noeuds sont élus , Il n'y a qu'un seul processus de consensus LeaderNoeud,ParLeader Entièrement responsable du retrait des transactions du pool 、 Emballer les transactions pour former des blocs et les mettre en chaîne ;
  • Follower:ParLeader Synchronisation des noeuds ,Et dansLeader Lorsque le noeud tombe en panne, une élection est tenue pour choisir un nouveau LeaderNoeud;
  • Candidate:Follower Noeud en campagne Leader Statut temporaire .
2.1.3.2 Durée du mandat

Raft L'algorithme divise le temps en périodes de durée indéterminée Terms,Terms Pour les nombres consécutifs .ChaqueTerm En commençant par les élections , Si les élections sont couronnées de succès , Par le courant leader Responsable de la sortie , Si l'élection échoue , Aucune nouvelle unité n'a été élue Leader, Ouvre un nouveau Term, Reprise des élections .

2.1.3.3 Durée du mandat

2.1.4. Processus de base

Raft Le flux de base de l'algorithme est organisé en deux parties ,LeaderÉlections et copie des journaux.

2.1.4.1 leader Elections

Insérer la description de l'image ici

Raft Le mécanisme du rythme cardiaque est utilisé dans le module consensus pour déclencher LeaderElections. Quand le noeud démarre ,Le noeud devient automatiquementFollowerEtTermPosition0.Tant queFollowerDeLeaderOuCandidate Reçu valide HeartbeatOuRequestVoteMessage, Il restera FollowerStatut,SiFollowerPendant un certain temps(Cette période s'appelle Election Timeout) Aucun message n'a été reçu , Il suppose que le système actuel Leader Déjà inactivé , Puis ajoutez votre propre TermEt converti enCandidiate,Ouverture d'un nouveau cycleLeaderProcessus électoral,Le processus est le suivant:

  1. FollowerAjouter leTerm,Convertir enCandidate;
  2. Candidate Votez pour vous - même ,Et diffuserRequestVote Demander un vote à un autre noeud ;
  3. Candidate Le noeud reste CandidateStatut, Jusqu'à ce que l'une des trois situations suivantes se produise :
    1. Le noeud a gagné l'élection ,, C'est - à - dire qu'il a obtenu plus de la moitié des votes du serveur ,Devenir Leader;
    2. En attendant les élections ,Candidate Reçu d'autres noeuds Heartbeat, Il y a d'autres noeuds qui ont obtenu plus de la moitié des votes ;
    3. Passe.Election TimeoutAprès,Non.LeaderÉlu.

Raft L'algorithme utilise une méthode de minuterie aléatoire pour éviter le partage moyen des votes des noeuds afin de s'assurer qu'il n'y a qu'un seul noeud dans la plupart des cas. Candidate Statut et obtenir la majorité des votes des noeuds deviennent Leader.

  • Processus de vote

Le noeud reçoitVoteReqAprès le message, Différentes politiques de réponse sont sélectionnées en fonction du contenu du message :

  1. VoteReqDeTerm Inférieur ou égal à son propre Term

    • Si le noeud estLeader, Rejeter la demande de vote ,Candidate Une fois cette réponse reçue, l'élection sera annulée et convertie en Follower, Et augmenter les délais de vote ;
    • Si le noeud n'est pasLeader:
      • SiVoteReqDeTerm Plus petit que son Term, Rejeter la demande de vote ,SiCandidate Plus de la moitié de ces réponses indiquent qu'elles sont obsolètes ,En ce momentCandidate Abandonner l'élection et se transformer en Follower, Et augmenter les délais de vote ;
      • SiVoteReqDeTerm égal à son propre Term, Rejeter la demande de vote , La demande de vote n'est pas traitée .Pour chaque noeud, On ne peut voter qu'une seule fois, selon le principe du premier arrivé, premier servi. Candidate, De sorte qu'au plus une élection par tour CandidateSélectionné commeLeader.
  2. VoteReqDelastLeaderTerm Plus petit que son lastLeaderTerm

    Un par noeud lastLeaderTerm Le champ représente le dernier que ce noeud a vu LeaderDeTerm,lastLeaderTerm Seulement par HeartbeatMise à jour.SiVoteReqDanslastLeaderTerm Plus petit que son lastLeaderTerm,Ça veut direLeaderAccédez à ceciCandidateIl y a un problème.,SiCandidate Dans l'environnement d'une île en réseau , Les demandes de vote sont constamment présentées à l'extérieur , Il faut donc interrompre sa demande de vote. , Le noeud rejette donc la demande de vote .

  3. VoteReqDelastBlockNumber Plus petit que son lastBlockNumber

    Un par noeud lastBlockNumber Le champ indique la hauteur du bloc du dernier bloc vu par le noeud . En sortant du bloc , Copie en bloc entre noeuds (Voir détails3.2Section), Pendant la réplication des blocs , Certains noeuds peuvent avoir reçu des données de bloc plus récentes et d'autres non , Ce qui conduit à des noeuds différents lastBlockNumberIncohérence. Afin de permettre au système de parvenir à un accord , Exiger que le noeud vote pour le noeud avec des données plus récentes , Par conséquent, dans ce cas, le noeud rejettera la demande de vote .

  4. Le noeud est le premier vote

    Pour éviterFollower Redémarrer l'élection en raison de la nervosité du réseau , Indique si le noeud est le premier vote , Rejeter directement la demande de vote , En même temps, il va mettre son firstVote Le champ est défini à ceci Candidate Index des noeuds pour .

  5. 1~4 Aucune des étapes n'a rejeté la demande de vote

    Accepter la demande de vote .

  • Temps d'arrêt cardiaque

    InLeader En devenant une île Internet ,Leader Peut faire battre son cœur 、Follower Peut recevoir un battement de cœur, mais Leader Pas de réponse cardiaque ,Dans ce casLeader Une exception réseau s'est produite à ce stade , Mais comme il est toujours possible d'envoyer des paquets de battements de cœur à l'extérieur Follower Impossible de changer d'état pour la sélection , Le système est bloqué . Afin d'éviter une deuxième situation , Le mécanisme de temporisation cardiaque est défini dans le module ,Leader Chaque fois qu'une réponse cardiaque est reçue, elle est enregistrée. , Une fois que l'enregistrement n'a pas été mis à jour après un certain temps LeaderAbandonne.Leader Identité et conversion en FollowerNoeud.

2.1.4.2 Copie du Journal

Insérer la description de l'image ici

Raft Forte dépendance du Protocole Leader Disponibilité des noeuds pour assurer la cohérence des données du cluster . Les données ne peuvent être acheminées qu'à partir de Leader Direction nodale Follower Transfert de noeuds .

Quand Client Au Cluster Leader Une fois que le noeud a soumis les données ,Leader Les données reçues par le noeud sont dans un état non engagé (Uncommitted),

Et voilà. Leader Les noeuds vont simultanément à tous Follower Le noeud copie les données et attend une réponse , S'assurer qu'au moins la moitié des noeuds du cluster ont reçu des données Client Confirmer que les données ont été reçues .

Une fois que Client Envoyer la réception des données Ack Après la réponse, Indique que l'état des données est maintenant soumis (Committed),Leader Le noeud se dirige vers Follower Le noeud envoie une notification indiquant que l'état des données a été soumis .

2.2 PBFT

2.2.1 Introduction

  • Conclusions:

    La complexité temporelle estO(n^2),Peut résoudre le problème byzantin.PBFT L'algorithme peut tolérer moins de 1/3 Noeuds invalides ou malveillants . S'il y a nMachine, Le système tolère le plus le mal. / Le noeud de défaut est (n-1)/3- Oui.. Le nombre total de noeuds du système est :|R| = 3f + 1.

  • Processus de certification

    Parce qu'on sait qu'il y af Les noeuds du mal ,Nous devons doncn-f Dans la communication des réplicateurs d'état , Une décision est sur le point d'être prise . Et nous ne pouvons pas prédire f Qu'est - ce qu'un noeud maléfique a fait? (Messages d'erreur/Ne pas envoyer), Donc nous ne savons pas ,Voilà.n-f Plusieurs d'entre eux sont des noeuds méchants. , Nous devons nous assurer que les noeuds normaux sont plus grands que le nombre de noeuds qui font le mal .Donc il y a n-f-f > f,Et doncn > 3f.

  • Mécanisme de détermination du noeud Maître :

    Le noeud maître est déterminé par un ensemble de numéros de vue et de noeuds ,C'est - à - dire::Noeud maître p = v mod |R|.v: Voir le numéro ,|R|Nombre de noeuds,p: Numéro du noeud principal .

2.2.2 Processus de consensus

Répartition des rôles

  • Client: Noeud client, Responsable de l'envoi des demandes de transaction .
  • Primary: Noeud maître, Responsable de l'emballage des transactions en blocs et en blocs de consensus , Il n'y a qu'un seul consensus par cycle PrimaryNoeud.
  • Replica: Noeud de copie, Responsable du Consensus de bloc , Il y a plus d'un consensus par cycle ReplicaNoeud,ChaqueReplica Le traitement des noeuds est similaire .

Parmi eux,PrimaryEtReplica Les noeuds sont tous des noeuds de consensus .

Processus de base

PBFT Le processus de base de l'algorithme comporte les quatre étapes suivantes :

  1. Le client envoie une demande au noeud maître
  2. Demande de diffusion du noeud maître à d'autres noeuds ,Exécution des noeudsPBFT Processus de consensus en trois étapes pour l'algorithme .
  3. Une fois que le noeud a terminé le processus en trois étapes , Retourner le message au client .
  4. Le client a reçu de f+1 Après le même message pour les noeuds , Le consensus des délégués a été dûment complété .
    Insérer la description de l'image ici

Processus de base

Les trois principales étapes de l'algorithme sont les suivantes: pre-prepare Phase( Phase de préparation ),prepare Phase(Phase préparatoire), commit Phase(Phase de soumission).Dans l'imageCReprésenter le client,0,1,2,3 Numéro représentant le noeud ,Parmi eux0 Est le noeud principalprimary,Frappe!×De3 Peut représenter un noeud défectueux ou un noeud fautif , Le comportement ici est de ne pas répondre aux demandes d'autres noeuds . L'ensemble du processus est le suivant: :

Tout d'abord,,Client à maître0Demande d'initiation<<REQUEST,o,t,c>>Parmi euxtC'est l'horodatage,oOpérations de représentation,cC'est çaclient, Le noeud maître a reçu une demande du client , Envoyé à d'autres noeuds pre-prepare Message, Les autres noeuds l'ont reçu. pre-prepare Message, C'est le début d'un processus de consensus en trois étapes. .

  • Pre-prepare Phase:Noeud de copiereplicaBien reçu. pre-prepare Message<<PRE_PREPARE,v,n,d>,m>Après, Déterminer si le message est reçu .Parmi eux,v Représente le numéro de vue ,n Représente le numéro de série du message ( Chaque demande que le noeud maître reçoit d'un client est marquée d'un numéro ),d Résumé du message du représentant ,m Représente les données brutes du message . Dans le message v Et n Le message que j'ai reçu est arrivé. ,Mais d Et m Mais ce n'est pas conforme au message précédent , Ou le numéro de la demande n Pas entre les niveaux d'eau élevés et bas , La demande est rejetée. . La logique de rejet est que le noeud maître n'envoie pas deux des mêmes v Et n ,Mais... d Et m Mais les nouvelles sont différentes .

    RepliaLe noeud a reçupre-prepareMessage, Effectuer la validation du message suivante :

    • MessagemValidité de la signature, Et un résumé du message dEt le messagemÇa correspond:d=hash(m)
    • Le noeud est actuellement en vue vMoyenne
    • Le noeud est actuellement dans le même (view v ,sequence n) Il n'y a rien d'autre pre-prepareMessage, Il n'y en a pas d'autre. m’Et correspondantd’ ,d’=hash(m’)
    • h<=n<=H,HEthReprésente le numéro de sérienLes niveaux d'eau élevés et bas.
  • Prepare Phase: Une fois que le noeud actuel accepte la demande, elle sera envoyée à d'autres noeuds. prepare Message<PREPARE,v,n,d,i> Enregistrer également le message à logMoyenne,Parmi euxi Utilisé pour représenter l'identité du noeud actuel . Il n'y a pas qu'un seul noeud en même temps ,Peut - être. n Les noeuds font le même processus . Il est donc possible que le noeud reçoive l'envoi d'autres noeuds prepare Message,Noeud actueliVérifiez - les.prepare Le message et le message prepareMessagev,n,d Les trois données sont - elles cohérentes? .Après validation,Noeud actueliOui.prepared(m,v,n) Set totrue,prepared(m,v,n) Au nom du noeud de consensus (v,n) Pour le message mDePrepare La phase est - elle terminée? .Dans un certain délai, Si vous recevez plus de 2f D'autres noeuds prepare Message,Juste au nom de prepare Phase terminée. Noeud de consensus final iEnvoyercommit Message et entrée CommitPhase.

  • Commit Phase:Noeud actueliReçu2f D'autres noeuds de consensus commitMessage<COMMIT,v,n,d,i> Insérer le message en même temps logMoyenne( Compte tenu de ce que tu as en commun 2f+1- Oui.),Vérifiez - les.commit Des nouvelles et des messages personnels commitMessagev,n,d Une fois que les trois données sont cohérentes, , Le noeud de consensus committed-local(m,v,n)Set totrue,committed-local(m,v,n) Déterminer le message au nom du noeud de consensus m A obtenu au moins 2f+1 Consensus des noeuds , Et cela garantit au moins f+1- Oui.non-faulty Le noeud a déjà répondu au message mParvenir à un consensus. Le noeud exécute la requête ,Écrire des données.

Après le traitement, Le noeud renvoie le message <<REPLY,v,t,c,i,r>>Aux clients, Lorsque le client recueille f+1 Après un message , Consensus terminé ,C'est ça.PBFT Tout le processus de l'algorithme .

prepareEtcommit Pourquoi toutes les étapes 2f+1 Confirmation de la rétroaction des noeuds ?(Voilà.2f+1 Ce n'est pas nécessairement la même chose. )
Dans le pire des cas : Nous supposons que nous recevons f C'est un noeud normal. ,Il y en a aussi.fOui.Noeud malveillantJe l'ai envoyé.,Alors,No2f+1 Ça ne peut venir que de noeuds normaux. .C'est ce que je vois.,“La plupart” Les noeuds normaux peuvent encore faire fonctionner le système .Alors...2f+1Ce paramètre etn>3f+1 L'exigence est logique et auto - cohérente .

client Pourquoi seulement f+1 Même réponse pour confirmer ?

​ On a dit ,prepareEtcommit Pourquoi toutes les étapes 2f+1 Commentaires des noeuds ,Pour confirmer.clientC'est tout.f+1Même chose.replyC'est bon? On va penser au pire. , Supposons que f+1Même chose.replyMoyenne,Oui.f Tous des noeuds malveillants .

Donc au moins unrely Ça vient d'un noeud normal. ,Parce quepreparePhase, Ce noeud normal est déjà garanti prepared(m,v,n,i)C'est vrai., Pour représenter la majorité ,Alors...,clientC'est tout.f+1Même chose.reply Pour s'assurer qu'il a tout le système “ La plupart des noeuds normaux “Observations, Pour parvenir à la cohérence .

Résumé: Si ça se passe bien,, Un noeud a reçu 1- Oui.pre-prepareMessages et2fEtprepareEntrée du messagecommitPhase,2f+1- Oui.commit Après le message replyVoilà.client,clientBien reçu.f+1 Les réponses confirment le succès de la soumission .

2.2.3 Recyclage des déchets

Selon la section algorithme précédente, vous pouvez trouver , Nous devons continuer logInsérer un message,Inview change Le temps de récupération est nécessaire .Et donc,log Ça va bientôt prendre beaucoup de mémoire , Il y a un moyen de nettoyer ce qui est inutile. log.Quand unrequestA étéf+1 Après l'exécution des noeuds normaux , Et quand view change L'état actuel peut être justifié pour d'autres noeuds ,AvecrequestQuestions connexesmessageVous pouvez supprimer.

QuandrequestNuméro de sérien % C ( Un Un. Allez Valeur ) =0Heure,Produire uncheckpoint,NoeudiMessages Multicast<<CHECKPOINT,n,d,i>>Aux autres noeuds, Quand le noeud reçoit 2f+1Message (s),LecheckpointDevientstable checkpoint,C'est ça.2f+1 Les noeuds peuvent prouver l'exactitude de cet état , Vous pouvez également supprimer le numéro de séquence ≤n Le message de logInformation etcheckpointInformation.

  • checkpoint: Le noeud actuel gère Dernier numéro de demande .
  • stable checkpoint ( Point de contrôle de stabilité ):stable checkpoint C'est la plupart des noeuds (2f+1- Oui.) Nombre maximal de demandes acceptées .
  • Niveau d'eau élevé et bas : Les basses eaux sont stable checkpointNuméro de sérien, Les hautes eaux sont stable checkpointNuméro de sérien + K,Parmi euxKEst une valeur fixe,En généralC( Une certaine valeur mentionnée ci - dessus )Nombre entier de fois de.

2.2.4 Remplacement de la vue (view change)

Quand Le noeud maître a rencontré une erreur ou est devenu un noeud malveillant Heure,C'est ce qu'il faut faire Remplacement de la vue (view change),C'est le choix( Méthode de rotation )Suivant.replica Noeud en tant que noeud Maître , Voir le numéro vEn cours+1Fonctionnement, Le processus de consensus passe à l'étape suivante view.

Insérer la description de l'image ici

Comme le montre la figure, view change Il y aura trois étapes,Respectivement. view-change , view-change-ack Et new-viewPhase.

  • replica Noeud considéré comme maître primaryEn cas de problème, Envoyé à d'autres noeuds view-change Message<<VIEW−CHANGE,v+1,n,C,P,i>>
    • v: Numéro de vue précédent
    • n:NoeudiDestable checkpointLe numéro de
    • C:2f+1 Valide pour les noeuds checkpointCollecte d'informations
    • P:Noeudi Le nombre dans la vue précédente est supérieur à n Et atteindre prepared Une collection de messages de demande d'état
    • i: Numéro du noeud
  • Le noeud actuellement en vie avec le plus petit nombre de noeuds deviendra le nouveau noeud maître . Lorsque le nouveau maître reçoit 2f D'autres noeuds view-change Message, Il est prouvé qu'il y a suffisamment de noeuds qui pensent que le noeud maître a un problème , Et il diffuse à d'autres noeuds new-view Message<<NEW-VIEW,v+1,V,O>>
    • v: Numéro de vue précédent
    • V: Le nouveau noeud maître a reçu un numéro de vue valide de v+1Deview-changeCollection de messages
    • O:pre-prepare Une collection de messages .Hypothèses O Plage de numérotation des messages dans la collection :(min~max),Et Min Pour V La plus petite collection stable checkpoint , Max Pour V Le plus grand ordinal de la collection prepare Message.Dernière étape O Dans la collection pre-preapare Message, Il y a deux cas par message : Si max-min>0, Le message est généré <<pre-prepare,v+1,n,d>> ;Si max-min=0, Le message est généré <<pre-prepare,v+1,n,d(null)>>

Attention!:replica Le noeud ne lance pas new-view Événements. Pour le noeud Maître ,Envoyer new-view L'exécution des demandes non traitées dans la vue précédente se poursuit après le message ,De pre-prepare Début de la phase. Validation des autres noeuds new-view Après le passage du message , Il s'occupera de l'envoi du noeud principal pre-prepare Message, Le processus d'exécution est décrit ci - dessus. PBFTProcessus.À ce moment - là,Entrée officielle v+1 ( Voir le numéro plus 1)C'est l'heure..

  • raftEtpbftComparer
    Insérer la description de l'image ici

3 Algorithme de consensus de la chaîne publique

3.1 POW

3.1.1 Explication du nom

  • Structure des blocs de zone

    La taille du bloc est 80Octets,Par4Numéro de version en octets、32 Valeur de hachage du bloc précédent d'octets 、32OctetsMerkle La valeur de genhachi 、4L'horodatage des octets(Heure actuelle)、4 Valeur cible de l'octet 、4 Composition aléatoire des octets .

Insérer la description de l'image ici

  • Valeur de difficulté

    Le bloc de bitcoin est d'environ 10Générer une minute, S'il est nécessaire de calculer la force à l'échelle du réseau dans des conditions différentes , La production de nouveaux blocs maintient essentiellement ce taux , La valeur de difficulté doit être ajustée en fonction de la variation de la force de calcul à l'échelle du réseau. .En termes simples, Les valeurs de difficulté sont fixées indépendamment de la capacité de calcul du noeud , Le taux de production de nouveaux blocs est maintenu à chaque 10Une minute..

    Le réglage de la difficulté se produit automatiquement indépendamment dans chaque noeud complet .Chaque2016Blocs, Tous les noeuds ajustent automatiquement la difficulté selon une formule uniforme , Cette formule a été mise à jour par 2016 Durée des blocs et durée prévue ( La durée prévue est 20160Minutes, Deux semaines , C'est à chaque 10 Durée totale calculée à partir du taux de production d'un bloc par minute ) Comparé à , Selon le rapport entre la durée réelle et la durée prévue ,Ajuster en conséquence( Ou plus difficile ou plus facile ).C'est - à - dire, Si le bloc produit un rapport de vitesse 10 Plus vite, plus difficile. ,Que10 Les minutes plus lentes réduisent la difficulté .

    Cette formule peut être résumée comme suit: : Nouvelle valeur de difficulté = Ancienne valeur de difficulté ×(Le passé.2016 Durée des blocs /20160Minutes)

  • Valeur cible

    Valeur cible de la preuve de la charge de travail bitcoin (Target)Formule de calcul pour:Valeur cible= Valeur cible maximale /Valeur de difficulté

    Où la valeur cible maximale est une valeur constante ,La difficulté est1 Valeur cible à ,C'est - à - dire:2^224:0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

    La valeur cible est inversement proportionnelle à la difficulté . La preuve de la charge de travail de bitcoin est que le hachage de bloc calculé par le mineur doit être inférieur à la valeur cible. .

3.1.2 Processus de consensus

BitcoinPoWProcessus, Il est facile de comprendre que les réalisations diffèrent nonceValeur en entrée,Essayez.SHA256Opération de hachage, Trouver un nombre donné d'en - têtes satisfaits 0 Le processus de hachage pour . Et le précurseur demandé 0 Plus il y en a , Plus il est difficile de représenter . Les étapes du noeud bitcoin pour résoudre le problème de preuve de la charge de travail sont résumées comme suit: :

  • Le noeud recueille les transactions à confirmer à l'échelle du réseau après la génération du bloc précédent , Enregistrer les transactions admissibles dans le pool de mémoire de transaction , Puis mettre à jour et calculer les transactions dans le pool de mémoire MerkleValeur de la racine, Et l'écrire à l'en - tête du bloc ;
  • Nombre aléatoirenonceIn0À232Valeur entre, Hacher l'en - tête du bloc , Lorsque la valeur de hachage est inférieure ou égale à la valeur cible , Package and Broadcast the Block , Terminer la tenue de livres après vérification par d'autres noeuds ;
  • Si la valeur de hachage requise ne peut être calculée dans un certain délai ,Répétez l'étape2. Si d'autres noeuds ont terminé le calcul pendant le calcul ,Par étapes1Recommencer.

Insérer la description de l'image ici

3.2 POS

PoS(PowofStake) C'est - à - dire le certificat de participation ,C'est pour résoudre PoW Algorithmes Un autre algorithme proposé pour résoudre le problème du gaspillage massif des ressources , L'algorithme est compatible avec PoW Compte. La plus grande différence dans la méthode est que le droit de tenue de livres du bloc est obtenu par le noeud avec les capitaux propres les plus élevés , Au lieu du noeud le plus puissant .

Le noeud obtient le droit de tenue de livres en fonction de l'âge de la monnaie consommée dans le processus de consensus , Plus l'âge de la monnaie consommée par le noeud est élevé , Plus vous avez de chances d'obtenir des droits de tenue de livres Grand. Le principe de la chaîne principale de l'algorithme est : La chaîne qui consomme le plus de pièces est celle qui est correcte et efficace dans le système . Dans la pièce PoS La formule de détermination du bloc qualifié de l'algorithme est la suivante: :

ProofHash<Target×CoinAge

Parmi eux,ProofHash Hachage correspondant à un ensemble de données ,Omis ici;CoinAge C'est l'âge de la pièce (coin*age);Target Est la valeur cible actuelle ,Même chose. PoW C'est pareil, Inversement proportionnel à la difficulté .

Target=PrevTarget×(1007×10×60+2×Tgap )/1009× 10×60

Parmi eux,PrevTarget Pour la valeur cible du bloc précédent ;2×Tgap Pour les deux premiers Intervalle entre les blocs .

L'intervalle actuel entre deux blocs est supérieur à 10 minHeure, Comparaison des valeurs cibles actuelles La valeur cible du bloc précédent augmente , C'est - à - dire que la difficulté actuelle du bloc sera réduite ;

Au contraire, L'intervalle actuel entre deux blocs est inférieur à 10 min, La valeur cible actuelle est comparée à La valeur cible du bloc diminue , C'est - à - dire que la difficulté actuelle du bloc augmentera .

PoS Transformer la concurrence du pouvoir de calcul en concurrence des capitaux propres , Non seulement les économies Force, .L'introduction d'intérêts peut également empêcher les noeuds de lancer des attaques malveillantes ; Même chose. Tous les noeuds sont responsables du maintien d'un fonctionnement sûr et stable de la chaîne de blocs. Pour protéger ses propres intérêts ; PoS Bien qu'il réduise la consommation de ressources informatiques , Mais il n'a pas résolu le problème de la centralisation accrue , La naissance du nouveau bloc Devenir un noeud qui tend à avoir des intérêts élevés .PoS Vous devez avoir la moitié du réseau Les intérêts de 51%Attaque, Mais c'est plus cher que d'avoir un super réseau. Un demi - Calcul [70], En outre, la création d'un bloc nécessite la consommation de capitaux propres , De faire PoS En cours 51% La difficulté de l'attaque augmente , Dans une certaine mesure Risques pour la sécurité[31]

3.3 DPOS

DPoS(Delegated ProofofStake)C'est - à - dire: Unité Droits Enseignement Droits Carte Ming Machine Faire,C'est... PoS Un algorithme dérivé de , L'idée de l'algorithme est que les noeuds détenant des intérêts dans le système Votent pour élire une partie des représentants , Ces représentants se relaient ensuite pour obtenir des droits de tenue de livres par blocs. , Un peu comme une société par actions “Conseil d'administration”.

DPoS L'algorithme divise les noeuds en deux parties : Les électeurs qui ont voté Et Représentants élus .

Chaque noeud peut convertir ses intérêts détenus en votes pour Un noeud en qui on a confiance , Plus vous détenez d'intérêts , Plus le vote est important Élevé, Celui qui a obtenu le plus grand nombre de voix n Noeuds sélectionnés comme témoins (Witness)C'est - à - dire: Génération Tableau. La liste des témoins est remplacée par une nouvelle élection pour chaque période déterminée. Une fois. Participation directe des témoins au processus de consensus et de validation du bloc , Dans un règlement Au fil du temps, ils sont disposés au hasard et emballent les transactions à tour de rôle , Générer une nouvelle connexion de bloc Sur la plus longue chaîne . Chaque bloc généré , Le témoin obtiendra m%De Frais de manutention,m Les valeurs sont fixées sur proposition des témoins et sont décidées par les électeurs .Quand Mais, La participation à la campagne des témoins est également soumise à un dépôt important ,Voilà., Les témoins investissent le plus d'argent dans le système , Maintenir activement le Département pour assurer ses propres intérêts Sécurité du système .

Insérer la description de l'image ici

Références

  1. Décodage de sept types d'algorithmes de consensus de blockchain par un texte long de dix mille caractères
  2. Bcos Raft
    Quand Mais, La participation à la campagne des témoins est également soumise à un dépôt important ,Voilà., Les témoins investissent le plus d'argent dans le système , Maintenir activement le Département pour assurer ses propres intérêts Sécurité du système .

Références

  1. Décodage de sept types d'algorithmes de consensus de blockchain par un texte long de dix mille caractères
  2. Bcos Raft
  3. Une des familles d'algorithmes consensuels :raftEtpbftAlgorithmes
版权声明:本文为[Zhangtuo2018]所创,转载请带上原文链接,感谢。 https://netfreeman.com/2022/01/202201080446176394.html