Cryptomonnaie

Défis des contrats intelligents orientés objet – Blue Bear Digital Inc. – Medium

Défis des contrats intelligents orientés objet - Blue Bear Digital Inc. - Medium


La bataille entre évolutivité et confiance

Travailler avec des contrats intelligents sur une plate-forme comme Ethereum est un défi intéressant si vous avez passé beaucoup de temps à travailler dans un environnement de développement logiciel plus conventionnel. Une fois déployé, un contrat intelligent ne peut jamais être supprimé du réseau. Par conséquent, le comportement par défaut est sa longévité.

Dès le début, des dispositifs tels que des commutateurs de neutralisation sont apparus pour essentiellement résilier un contrat en cas de problème. Ces commutateurs de neutralisation ne peuvent pas être activés par n'importe qui, mais doivent généralement l'être par le ou les créateurs du contrat (c'est-à-dire qu'il s'agit de fonctions de contrôle centralisées).

Ces commutateurs de neutralisation simples soulignent un compromis extrêmement important en informatique décentralisée: évolutivité contre. confiance.

Évolutivité

La capacité d'évolution peut être définie comme la capacité pour les programmeurs de modifier le comportement d'un logiciel à un moment donné dans le futur.

Les interrupteurs Kill entrent clairement dans cette définition, même dans un sens limité. Les commutateurs de neutralisation devraient généralement être préprogrammés dans le contrat et seraient donc transparents pour un utilisateur astucieux (mais probablement pas pour un utilisateur moyen). Une classe plus étendue de possibilités de mise à niveau comprendrait la possibilité de publier du code supplémentaire ou modifié représentant des modifications ou des améliorations apportées au système.

La possibilité de mettre à niveau les contrats intelligents est souhaitable au sens large pour un certain nombre de raisons:

  • Correction des défauts dans le code quand ils sont trouvés
  • Mise à niveau de la base de code lorsque de nouvelles normes apparaissent ou recherche de méthodes plus efficaces
  • Changer le comportement du code à mesure que les exigences évoluent

Il est important de noter que ces aspects sont souhaitables pendant le développement et après le déploiement. Un système complètement inflexible devient difficile à développer lorsqu'il atteint une certaine taille. Il est courant de voir des contrats intelligents comportant des centaines et des centaines de lignes. Ils contiennent généralement leur propre stockage de données, manipulé par des règles commerciales définies dans le même contrat.

Nous avons commencé à expérimenter il y a quelques temps: scinder le code qui représente les règles commerciales en contrats distincts du code qui gère simplement les données. Pour être efficaces, les règles métier doivent avoir la capacité de modifier l’état des données. Dans la mesure où la sécurité d’un environnement de programmation Blockchain tel que Solidity repose en grande partie sur le comportement restrictif basé sur: msg.sender, séparer la logique du contrat de manipulation des données signifie que vous avez besoin contrats protégés- des contrats non exposés au monde extérieur. Ces contrats ne peuvent être appelés que par d’autres contrats ou adresses figurant sur la liste blanche.

La scission des données et du comportement dans des contrats séparés introduit plusieurs propriétés intéressantes.

Tout d’abord, la migration des données sur la Blockchain pose problème pour un certain nombre de raisons. L'encapsulation du stockage de données avec une fonctionnalité CRUD simple dans son propre contrat réduit la probabilité que le contrat contenant doive être modifié. Ce n’est pas encore nul. Pensez au nombre de fois où les tables de la base de données sont modifiées. Toutefois, le transfert des règles métier dans leurs propres contrats distincts nous permet de mettre à niveau la logique du système sans avoir à recréer l'état des données.

De plus, la division de la logique de stockage des données et de la logique commerciale nous permet de définir des interfaces stables pour des sujets spécifiques tout en maintenant la flexibilité de mise en œuvre.

C'est génial pour deux raisons.

Premièrement, c’est une bonne pratique logicielle de ne pas dépendre de choses que vous n’utilisez pas. Ainsi, si un système externe dépend d’un ensemble spécifique de fonctionnalités de notre système, il est utile s’il peut uniquement dépendre de ce sous-ensemble de fonctionnalités et non de tout ce qui se trouve dans notre système.

A titre d'exemple, supposons que nous ayons un système de contrat intelligent pour la location de voitures. Nous décidons de mettre tout le code dans Un gros contrat ™. Notre contrat contient une logique concernant un certain nombre de choses, mais une tierce partie appelée CarRep s’intéresse uniquement à l’historique de la location de voitures par un nouveau système de réputation sur lequel elle travaille.

Lo and Behold, nous devons améliorer la manière dont les nettoyages de voitures sont enregistrés dans notre contrat. Nous résolvons donc le problème et déployons un nouveau contrat. Bien sûr, nous corrigeons toutes nos applications internes pour pointer vers le nouveau contrat et informer les personnes qui (nous savons) utilisent notre contrat du changement. Maintenant, CarRep doit changer de code car nous avons décidé de changer la façon dont nous traitons le nettoyage des voitures. Cependant, il existe une possibilité non nulle que nous ne sachions même pas à propos de CarRep, et si nous ne communiquons pas bien, nous venons de briser leur système.

Si nous avions divisé notre logique en différents contrats, CarRep n'aurait rien changé.

Deuxièmement, si nous définissons des interfaces de haut niveau qui pointent vers des implémentations de la logique métier, CarRep n'aurait besoin de changer leur code que si nous changions l'API publique de haut niveau (contrat de proxy). Si nous sommes prudents dès le départ avec nos définitions et nos noms, ces changements peuvent être rares. C’est essentiellement la même chose que nous attendons maintenant des versions majeures d’API publiques telles que Stripe ou Twitter.

Enfin, le modèle que nous avons défini permet à notre système de suivre le principe Open-Closed: nous sommes en mesure d’ajouter un nouveau comportement au système sans avoir à modifier le code source. Nous pouvons simplement déployer de nouveaux composants et les ajouter à la liste blanche si nécessaire pour qu'ils aient l'autorisation d'interagir avec notre système.

Confiance

L'une des premières idées promues en matière de contrats intelligents est le fait qu'ils sont contraignants - d'où le mot «contrat». Les descriptions ont quelque chose comme: «Joe et moi avons parié sur le vainqueur des élections. Une fois l’accord conclu, il ne peut plus être annulé. Une fois les élections terminées, le contrat intelligent récompensera le vainqueur. " En ce sens, les contrats intelligents sont également «sans confiance», car je peux entièrement compter sur le code à exécuter comme spécifié sans intermédiation.

Cela contraste nettement avec les arguments précédents concernant la nécessité de mettre à niveau les contrats. Si je peux à lui seul mettre à niveau un contrat, je peux alors faire toutes sortes de choses malveillantes ou biaisées, et j'ai réintroduit la nécessité pour les gens de me faire confiance.

Ceci présente un conflit fondamental. Comme le souligne Robert Martin dans son livre Clean Architecture,

"Le logiciel doit être souple - c'est-à-dire qu'il doit être facile à modifier."

Si je ne peux pas changer le code, toutes sortes de problèmes peuvent surgir. D'autre part, si un contrat peut changer, s'agit-il d'un contrat?

Une partie du problème réside peut-être dans le fait que le terme «contrat intelligent» est mal choisi. Certaines choses entreront certainement dans la catégorie des contrats, mais un environnement de programmation général tel que Solidity on Ethereum permet de créer toutes sortes de choses, dont certaines de nature moins contractuelle.

À mon avis, ce problème est loin d’être résolu. Cependant, je vais offrir quelques réflexions:

Premièrement, à l'échelle, je m'attendais à ce qu'un très petit nombre d'utilisateurs lisent réellement le code et comprennent ce qu'ils signent. Ainsi, dans ce sens, ils auront très souvent confiance que l'entreprise, le site Web, la plate-forme, etc. avec lesquels ils interagissent ne sont pas malveillants.

Deuxièmement, dans de nombreux contextes, ce problème peut être résolu en obligeant plusieurs développeurs à approuver les modifications en cours de déploiement. Cela réduira les risques qu'un développeur passe au rouge et vole les gens.

Troisièmement, pour les systèmes très sensibles, les auditeurs externes pourraient être tenus de valider les modifications en plus de plusieurs développeurs avant que les modifications ne soient repoussées. Les TCR pourraient être utilisés pour gérer des listes de développeurs et d'auditeurs approuvés dans les cas où une décentralisation totale est requise.

Ce sujet est profondément lié à un certain nombre de projets sur lesquels je travaille et je continuerai à étudier et à écrire à ce sujet au fur et à mesure que j'apprendrai de nouvelles choses.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close