web-dev-qa-db-fra.com

Les blocs sont-ils extraits dans le tissu HyperLedger?

Je lisais la documentation sur la manière dont le projet HyperLedger Fabric implémentait une solution open source BlockChain: https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md

J'ai vu que l'algorithme de consensus PBFT est utilisé, mais je ne comprends pas comment les blocs sont extraits et partagés entre tous les homologues de validation du réseau BlockChain.

blockchainhyperledger
11
Marc Cayuela Rafols

Les VP de Hyperledger Validating Peers ne minent pas les blocs et ne les partagent pas. Voici comment cela fonctionne:

  1. Une transaction est envoyée à un seul VP de confiance.
  2. Le VP diffuse la transaction à tous les autres VP.
  3. Tous les VP atteignent un consensus (en utilisant l'algorithme PBFT) sur l'ordre à suivre pour exécuter les transactions.
  4. Tous les VP exécutent les transactions "seuls" en suivant l'ordre total et construisent un bloc (calculant principalement les hachages) avec les transactions exécutées.

Tous les blocs seront identiques car: l'exécution de la transaction est déterministe (devrait être) et le nombre de tx dans un bloc est fixe.

27
Marc Cayuela Rafols

Selon Hyperledger Fabric 1.X

  1. L'utilisateur par le biais du client SDK envoie la proposition de transaction à ses homologues.
  2. Endossing Peer vérifie la transaction et fait une proposition d’endossement de la transaction (avec un ensemble lecture/écriture (valeur précédente/valeur modifiée)) et l’envoie à nouveau au client SDK.
  3. Le client SDK attend toutes les endossements. Une fois qu'il a reçu toutes les propositions d'endossement, il formule une demande d'invocation et l'envoie au client.
  4. Le donneur d’ordre vérifie la location de la demande d’invocation par le SDK client en vérifiant les politiques définies (Consensus), vérifie la transaction et s’ajoute au blocage.
  5. Selon la configuration définie pour bloc, après le temps spécifié ou le nombre de transactions défini, il forme un hachage de bloc en utilisant le hachage de transaction, les métadonnées et le hachage de bloc précédent.
  6. Le client envoie sa réponse à tous ses pairs.
  7. Tous les homologues engagés vérifient toutes les transactions bloquées et mettent à jour le grand livre avec le nouveau bloc et l'état actuel de l'actif.

Grand livre contient 

  • 1) Base de données sur l’état actuel (niveau BD ou base de données Couch)
  • 2) Blockchain (Fichiers) (Blocs liés)

Vérifiez l'image pour référence  Hyperledger Fabric Transaction Flow

4
PAVAN

Hyperledger est un parapluie de technologies blockchain. Hyperledger Fabric, mentionné ci-dessus, en fait partie. Hyperledger Sawtooth n'utilise pas non plus l'extraction et ajoute les algorithmes de consensus suivants:

  • PoET Preuve du temps écoulé (algorithme de consensus de style Nakamoto facultatif utilisé pour Sawtooth). PoET avec SGX a BFT. PoET Simulator a CFT. Cela ne nécessite pas beaucoup de temps processeur, contrairement aux algorithmes de type PoW, bien qu'il puisse toujours fonctionner avec des blocs périmés. Voir la spécification PoET à https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html
  • RAFTAlgorithme de consensus qui élit un chef pour une durée de temps arbitraire. Leader remplacé si le délai est expiré. Raft est plus rapide que PoET, mais n'est pas BFT (Raft est CFT). De plus, le radeau ne bifurque pas.
  • Avec unpluggable consensus , un autre algorithme de consensus peut être modifié sans réinitialiser la blockchain ni même redémarrer le logiciel.

Pour être complet, l’algorithme de consensus original avec bitcoin (et fait utilise l’exploitation minière) est:

  • PoW Preuve de travail. Achèvement des travaux (algorithme de consensus de type Nakamoto exigeant beaucoup de temps pour le processeur). Habituellement utilisé dans les blockchains sans permission
0
Dan Anderson