Comment rendre les smart contracts évolutifs ?

La non-évolutivité des smart contracts est un problème de taille pour nombre de développeurs. Un ingénieur de chez iExec a publié son rapport sur le sujet revenant sur les méthodes qui permettrait de mettre à jour des smart contracts.

Dans l’ensemble de cet article, nous parlerons de smart contract et plus précisément ceux opérant sur la blockchain Ethereum grâce à l’EVM (Ethereum Virtual Machine).

Un problème d’évolutivité

Les smart contracts, sont des programmes informatiques faisant partie de certaines blockchains. Ils permettent d’exécuter des opérations sans tiers de confiance, de manière décentralisée tout en permettant un audit du code.

Cependant, une fois le contrat déployé sur une blockchain, il est impossible de modifier le code qu’il utilise et ainsi d’y apporter des améliorations.

Malgré que ces smart contracts aient été hautement testés et audités, la possibilité d’un bug dans le code ou le compilateur n’est pas impossible. Même sans bugs, certaines fonctionnalités n’ayant pas été envisagées ne pourront pas être ajoutées au code sur smart contract.

Le rapport de Hadrien Croubois

Hadrien Croubois – ingénieur chercheur chez iExec – a publié un rapport résumant ses travaux sur l’évolutivité des smart contracts, ainsi que sur les différentes approches pour implémenter des mécanismes de mise à jour de leur code.

Avant toute chose il faut comprendre comment est composé un smart contract. Celui-ci est composé de deux parties :

• Le bytecode, contenant la logique d’exécution
• La mémoire, contenant l’état du smart contract

Ainsi, les approches pour mettre à jour les smart contracts visent à modifier le bytecode – et donc les mécanismes du smart contract – sans toucher à la mémoire de celui-ci.

Les smart contracts Solidity disposent d’une manière d’appeler d’autres contrats avec la méthode delegatecall. C’est grâce à cela que l’on pourrait mettre à jour des smart contracts. On dispose d’un smart contrat principal – qui n’est pas modifiable – faisant office d’interface entre les développeurs et un « sous-smart contract » dont les logiques sont modifiables.

Dans ce cas, le smart contract principal – ou proxy – décrit les détails et les soldes des tokens et communique des instructions au sous-smart contract grâce aux delegatecall, le tout en gardant sa mémoire intacte. Ainsi, un seul déploiement – audité au préalable – est nécessaire et l’évolutivité est assurée.

En plus d’améliorer l’évolutivité, cela permettrait de réduire les ressources utilisées par le smart contract.

« En plus de la possibilité d’évolutivité, ces modèles permettent également d’économiser de la mémoire (et de l’argent) en partageant la logique entre les instances. » Hadrien Croubois 

L’ERC-1538

L’ERC-1538 – Ethereum Request for Comment – va plus loin dans cette délégation des tâches, en permettant de répartir la logique entre plusieurs smart contracts délégués.

L’équipe de iExec a mené des recherches sur une infrastructure test en implémentant l’ERC-1538. Cela leur a permis de mettre à jour les smart contracts au fur et à mesure ainsi que de monitorer la consommation de gas.

Cependant, malgré ces avantages l’équipe a pu constater les inconvénients de ce modèle.

L’auditabilité

Malgré que les contrats ERC-1538 soient publics et sécurisés, il est plus compliqué de vérifier leur code, car un utilisateur normal ne pourrait pas lire la mémoire du contrat. Cette dernière n’est pas accessible, car il y a les delegate smart contracts entre l’utilisateur et le smart contrat principal, détenant la mémoire.

La gouvernance

D’un côté faire confiance à un smart contract non évolutif c’est avoir confiance en l’audit de son code source ainsi qu’en la blockchain. De l’autre, faire confiance à un smart contrat évolutif revient aussi à faire confiance à son propriétaire.

En effet, un smart contrat peut être sécurisé à un moment t, ce n’est pas pour autant qu’après une mise à jour, il le soit toujours. Ainsi, lors de la mise à jour d’un smart contract évolutif, il faudrait s’assurer que l’ensemble des parties, potentiellement affectées par celle-ci, soient d’accord.

La compatibilité

Enfin, l’implémentation de tels schémas de smart contract implique de s’assurer que chaque nouvelle version des contrats délégués utilise les mêmes schémas de données à communiquer à la mémoire du smart contract principal.

Si l’on manquait à cette règle, cela pourrait avoir des effets graves. Réaliser un delegatecall sur un contrat ne partageant pas les mêmes schémas de données pourrait casser le smart contract principal et résulté au blocage des actifs.

Les implémentations de l’équipe iExec

Pour l’équipe d’iExec, l’ensemble de ces challenges n’a pas permis d’implémenter ce type de smart contract dans la version 3 de leur protocole.

Cependant, Hadrien a eu le feu vert pour continuer à travailler sur ces questions afin d’apporter une amélioration de l’expérience ainsi que de la sécurité des utilisateurs. C’est l’objectif du KitsuneWallet, un kit d’outils de développement permettant de construire des smart contracts évolutifs. Cela lui a valu plusieurs prix, dont un délivré par le Binance Lab.

We would like to introduce the next @Binance Labs Fellow, Hadrien Croubois (@Amxx), and his project @KitsuneWallet. Kitsune Wallet (formerly known as UUIP – Universally Upgradeable Identity Proxy) was also the winner of our 2019 #ETHParis bounty.https://t.co/gKEWvlYmlL

— Binance Labs Fund (@BinanceLabs) May 25, 2019

Les projets UniversalLogin et Shipl ont déjà commencé à intégrer des smart contracts évolutifs construits grâce au KistuneWallet.

[es_tradingview symbol= »binance:rlcbtc » interval= »D » height= »500″ colors= »Light »]