Le cycle de vie d’une transaction

blockchain-SGAT-transaction-bitcoin

Tout d’abord, il faut savoir qu’en fonction du type de réseau Blockchain (du protocole utilisé) le cycle de vie d’une transaction diffère. C’est le cas par exemple d’Hyperledger Fabric. En effet, dans la majorité des plateformes (Bitcoin et Ethereum notamment), le cycle de vie d’une transaction dépend habituellement de deux facteurs.

  • Le premier, l’ordre : les transactions sont ajoutées au registre dans un certain ordre et diffusées à tous les pairs.
  • Le second, l’exécution : les transactions sont exécutées de façon séquentielle, à l’aide d’un code lié à un smart-contract par exemple, par tous les pairs.

Afin que l’ensemble des pairs obtiennent le même état de registre, les transactions doivent systématiquement être exécutées de façon déterministe, c’est-à-dire que la même transaction doit toujours donner le même résultat, peu importe où et quand elle est exécutée.

Cependant, cette condition limite fortement la capacité d’un smart-contract à faire certaines actions. Ce qui est, par conséquent, l’une des raisons pour lesquelles les smart-contracts utilisent souvent un langage spécifique à un domaine en particulier. Il n’est généralement pas possible d’appliquer le déterminisme dans un langage à usage universel (par exemple Java ou Go).

Le modèle en trois étapes

En revanche, dans Hyperledger Fabric le cycle de vie d’une transaction est construit différemment :

  • Tout d’abord, au niveau de l’exécution, les transactions sont exécutées dans n’importe ordre, voire en parallèle.
  • En outre, concernant l’ordre, lorsqu’un nombre suffisant de pairs s’accordent sur les résultats d’une transaction, celle-ci est ajoutée au registre et diffusée à tous les pairs. A cette étape, les transactions sont ordonnées pour la première fois. Tant que les transactions ne sont pas ajoutées au registre, il n’y a pas de notions d’ordre de transaction.
  • Par la suite, au moment de la validation, chaque pair valide et exécute les transactions dans un ordre chronologique. C’est à ce moment que les pairs ont un ordre. Elles peuvent donc vérifier si une transaction ultérieure a été invalidée par une transaction antérieure. Par exemple, cela empêche qu’un article soit vendu deux fois, aussi appelé la double dépense, « double-spending ».

    Distinction entre l’exécution et la validation

     Ainsi, une distinction est à faire entre la mise en place d’une transaction (exécution) et la mise à jour du registre (validation). Une distinction qui peut avoir des conséquences intéressantes :

    • Premièrement, tous les pairs doivent mettre à jour le registre, et donc tous les pairs participent à l’étape de validation. Pourtant, tous les pairs n’ont pas besoin d’exécuter le smart-contract. Hyperledger Fabric utilise des politiques d’endossement afin de définir quels pairs doivent exécuter quelles transactions. Dans ces conditions, cela signifie qu’un chaincode donné (le smart-contract) peut être gardé privé des pairs qui ne font pas partie de la politique d’endossement.
    • De même, les transactions peuvent être exécutées avant d’être mises en ordre. Cela permet notamment aux pairs d’exécuter des transactions en parallèle, ce qui améliore le débit et donc la scalabilité de la plateforme.
    • Enfin, dans le modèle en 3 étapes « exécute-ordonne-valide », les résultats issus de l’exécution du smart-contract pour une transaction donnée sont explicitement convenus (selon la politique d’endossement) avant que la transaction ne soit ajoutée au registre. Le modèle en 2 étapes «ordonne-exécute » utilise un chaincode déterministe, ce qui sous-entend que les pairs s’accorderont sur le résultat de l’exécution d’un smart-contract. Rendre l’accord explicite permet donc d’utiliser un chaincode non déterministe, et c’est grâce à cela que nous pouvons écrire un chaincode en Go, Java ou Node.js.

    Politique d’endossement

    De plus, les politiques autour de l’exécution du chaincode peuvent être définit. Ces politiques d’endossement définissent quels pairs doivent s’entendre sur les résultats d’une transaction.

    Ci-dessous quelques exemples de ce que pourraient être les politiques d’endossement :

    • les pairs A, B, C et D doivent tous endosser les transactions de type X ;
    • une majorité de pairs dans le canal doit approuver les transactions de type Y ; ou
    • au moins 3 pairs parmi A, B, C, C, D, E, F et G doivent endosser des transactions de type W.


    Cependant, la politique d’endossement n’a pas pour responsabilité de s’assurer que le bon chaincode soit installé sur les bons pairs. Il est en revanche possible d’implémenter un mécanisme similaire permettant « l’endossement » et l’installation de packages de chaincodes.

    Comment fonctionne l’endossement ?

    Jusqu’à présent, le terme transaction a été utilisé de de façon assez vague. Dans le modèle en 2 étapes (« exécute-ordonne »), les notions d’exécution du chaincode et de mise à jour du registre sont regroupées en une seule et même idée : la transaction. Dans un modèle à 3 étapes, ces deux concepts sont séparés, ce qui fait que la notion de transaction est également divisée en deux.

    En effet, on commence par une demande de transaction. En réalité, il s’agit simplement d’un paquet d’informations utilisé pour déclencher un chaincode spécifique. La demande de transaction est envoyée à certains pairs pour endossement (approbation).

    Un pair endosseur exécute alors le chaincode, ce qui génère une vraie transaction pour le registre. Le pair endosseur signe ensuite la transaction et la renvoie au demandeur. Il s’agit en réalité de l’étape « Exécute » dans « exécute-ordonne-valide ».

    Une fois que le créateur de la demande reçoit suffisamment de signatures afin de satisfaire à la politique d’endossement, il peut soumettre la transaction (et les signatures) pour ajout dans le registre.

    Il s’agit alors de l’étape « Ordonne ».

    In fine, le fait d’adopter un endossement explicite des transactions avant leur inscription dans le registre offrent d’immenses possibilités.

    SGAT adopte une nouvelle approche des transactions blockchain

    Ainsi, en s’appuyant sur la technologie d’Hyperledger Fabric – qui permet de séparer le processus d’exécution des smart-contracts du processus de mise à jour du registre- SGAT offre au travers de ses solutions sur-mesure, des possibilités infinies et plusieurs améliorations par rapport à d’autres technologies Blockchain.

    Nos solutions offrent notamment :

    (i) un débit des transactions bien plus élevé que les solutions actuelles basées sur des réseaux Blockchain traditionnels tels que Bitcoin ou Ethereum ;

    (ii) la possibilité d’instaurer des règles de confidentialité précises,

    (iii) la mise en place de smart-contracts plus polyvalents et plus performants.

    Prêt à vous lancer dans l’utilisation de la blockchain pour votre entreprise  ?

    logo_sgat_header_white

    Services SGAT

    Blockchain & Entreprises

    Audit & Étude

    SGAT Technologies 2019 @ All Rights Reserved