RICM5 2018 2019 - UGAChain - Smart Contract
Smart Contract
Définition
Les « Smart Contracts » sont des contrats qui s’appuient sur la technologie Blockchain pour rendre infalsifiables leurs termes et les conditions de leurs exécutions.
Qu’est-ce qui rend un « Smart Contract » intelligent ? Alors qu’un contrat légal traditionnel définit les règles d’un accord entre plusieurs parties, un Smart Contract va plus loin et fige ces règles dans une Blockchain tout en assurant le transfert d’un actif – quel qu’il soit – lorsque les conditions contractuelles se vérifient.
Références : https://www.lemagit.fr/conseil/Blockchain-quest-ce-quun-Smart-Contract-et-a-quoi-ca-sert
Un Smart Contrat est essentiellement la logique métier utilisée dans une blockchain.
Par exemple un smart contrat pourrait mettre à jour la balance d'un compte bancaire en assurant que la somme d'argent nécessaire au débit est bien présente sur un compte avant d'effectuer ce dernier.
Références : https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger_Arch_WG_Paper_2_SmartContracts.pdf
Catégories de Smart Contract
Les Smart Contracts sont la logique métier des blockchains. Ils sont classés dans deux catégories suivant le cas d'usage :
- On-chain Smart Contracts
- Installed Smart Contracts
On-chain Smart Contracts
Ils sont exécutés quand une transaction survient dans la blockchain et ils sont stockés au cœur même de cette dernière.
Installed Smart Contracts
Ils sont exécutés avant que les transactions n'arrivent au "ledger" ou avant le lancement de l'application (le réseau).
Références : https://hackernoon.com/how-are-smart-contracts-executed-in-hyperledger-57efebf03f12
Smart Contract et Hyperledger
Les Smart Contract sont au coeur de l'implémentation des Blockchain. La plateforme open source Hyperledger facilite l'implémentation des Smart Contract, et donc la "business logic" qui régit le fonctionnement des Blockchain.
Exécution d'un Smart Contract au sein d'Hyperledger
La figure 1 montre comment une requête envoyée à un smart contract est traitée.
L'entrée comprend l'identifiant du contrat à utiliser, la requête de transaction, l'état courant du ledger et les éventuelles dépendances de la transaction.
L'interpréteur de contrat (le bloc du milieu) est chargé avec l'état courant du ledger et le code du smart contract. Quand l'interpréteur de contrat reçoit une requête il la vérifie immédiatement et la rejette en cas d'invalidité.
Les sorties appropriées sont générées si la requête est valide et acceptée. Ces sorties incluent un nouvel état du ledger et d'éventuels effets-secondaires.
Quand le traitement est terminé l'interpréteur empaquette le nouvel état, une attestation de validité et d'éventuels indices d'ordre pour le service de consensus. Ce paquet est envoyé au service de consensus pour un ajout final à la blockchain.
La couche Smart Contract valide chaque requête en s'assurant qu'elle est conforme à la politique et au contrat spécifiés pour la transaction. Les requêtes invalides sont rejetées et pourraient être inclues dans un bloc suivant le framework Hyperledger.
Les erreurs de validation sont classées en deux catégories :
- Les erreurs de syntaxe comprennent les entrées invalides, les signatures invérifiables et les transactions répétées (provenant d'erreurs ou de replay attacks). Les requêtes doivent être rejetées.
- Les erreurs de logique sont plus complexes et la décision de continuer le traitement doit être prise en fonction de la politique utilisée.
Le résultat de la validation d'une requête dans un smart contract est une transaction qui mène au nouvel état. La framework Hyperledger Fabric utilise des change sets pour représenter l'état de transition.
la séparation entre l'exécution du contrat et le consensus complique l'ajout à la blockchain. Par exemple deux requêtes exécutées en parallèle peuvent mener à des incohérences dans le contrat sauf si elles sont ordonnées d'une manière spécifique. En général la couche de consensus prend en charge cette mise en ordre des requêtes et le smart contract peut fournir des indices sur l'ordre.
Le traitement d'une requête peut générer des effets secondaires : des résultats qui ne sont pas capturés dans le delta state. Ces effets secondaires peuvent inclure des notifications d’événements, des requêtes à d'autres smart contract, des modifications des ressources globales, et même des actions irréversibles comme la libération d'informations sensibles ou l'envoi d'un paquet.
Références : https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger_Arch_WG_Paper_2_SmartContracts.pdf#page=4
Interaction entre les Smart Contracts et les composants Hyperledger
La figure suivante montre comment les Smart Contracts interagissent avec les différentes couches architecturales de Hyperledger.
Références : https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger_Arch_WG_Paper_2_SmartContracts.pdf