Contrats Ethereum Oracle : Pouvons-nous faire confiance à Oracle ?
Publié: 2022-03-11Cet article est la dernière partie d'une série en trois parties sur l'utilisation des contrats oracle Ethereum.
- La première partie était une introduction à la configuration, à l'exécution et au test du code avec le framework truffle.
- La deuxième partie a examiné un peu le code et l'a utilisé comme point de départ pour une discussion sur certaines fonctionnalités de code et de conception de Solidity.
Maintenant, dans cette dernière partie, j'aimerais poser les questions : qu'est-ce qu'on vient de faire, et pourquoi ? Et essayez de fournir des pistes de réflexion, espérons-le, qui suscitent la réflexion. Le jury ne sait toujours pas comment l'utilisation des oracles est liée à l'absence de confiance et ce que le mot «absence de confiance» en ce qui concerne la blockchain signifie réellement dans l'utilisation réelle. Au fur et à mesure que nous amènerons certaines de ces idées de leur forme conceptuelle à leur utilisation pratique, nous serons obligés de lutter et d'accepter des questions comme celle-ci. Alors commençons.
Récapitulatif : Pourquoi avons-nous besoin d'un oracle Ethereum ?
Cela va au cœur même de la nature de l'exécution de code sur la blockchain. Afin de satisfaire aux exigences d'immuabilité et de déterminisme, et en tant qu'artefact de la manière dont le code est réellement exécuté par les nœuds de la chaîne, un contrat intelligent est incapable d'atteindre directement l'extérieur de la blockchain pour bien faire quoi que ce soit.
Pour la plupart des programmeurs, ce fait introduit une façon de penser très peu naturelle. Si nous avons besoin de données quelque part, normalement nous nous connectons simplement à cela quelque part et les extrayons. Un contrat intelligent qui a besoin de données météo ? Connectez-vous simplement à un flux météo. Mais non; un contrat intelligent blockchain ne peut absolument pas faire cela ; si certaines données ne sont pas déjà sur la blockchain, le code du contrat n'y a pas accès au moment de l'exécution. Alors, la solution est d' avoir déjà les données nécessaires existantes sur la blockchain, au moment de l'exécution du contrat. Cela nécessite des machines externes qui, plutôt que d'extraire des données dans la chaîne, poussent des données sur la chaîne, spécifiquement pour une utilisation par d'autres contrats. Cette machinerie externe est l'oracle. Les données poussées sur la chaîne sont poussées dans un contrat oracle, qui a ensuite vraisemblablement pris des dispositions pour les partager avec d'autres contrats. Un exemple de cette configuration est précisément ce que nous avons construit et examiné dans les deux parties précédentes de cette trilogie d'articles.
Trous de sécurité flagrants
Pour moi, la question centrale impliquée dans toute blockchain publique est le mot T : confiance. À l'état pur, ce que font ces systèmes est de leur mieux pour garantir (aucune garantie parfaite n'est possible dans ce monde, mais aussi proche que possible) que nous n'avons pas à faire aveuglément confiance à aucune partie. Le lecteur astucieux a peut-être déjà remis en question certaines des failles de sécurité flagrantes dans l'exemple des paris sur la boxe. Je voudrais me concentrer sur ceux qui seront les plus importants pour notre discussion sur l'absence de confiance et sur son lien avec l'utilisation d'oracles avec des contrats intelligents.
1. Le propriétaire/responsable du contrat de pari peut être corrompu
A partir de la ligne 58 de BoxingBets.sol nous avons la fonction suivante :
/// @notice sets the address of the boxing oracle contract to use /// @dev setting a wrong address may result in false return value, or error /// @param _oracleAddress the address of the boxing oracle /// @return true if connection to the new oracle address was successful function setOracleAddress(address _oracleAddress) external onlyOwner returns (bool) { boxingOracleAddr = _oracleAddress; boxingOracle = OracleInterface(boxingOracleAddr); return boxingOracle.testConnection(); }
Il devrait être assez clair ce que cela permet. Le titulaire du contrat (et uniquement le titulaire du contrat) peut, à tout moment et sans aucune restriction, modifier l'oracle utilisé pour servir les matchs de boxe et déterminer les gagnants. Pourquoi c'est un problème? Si ce n'est pas déjà évident pour vous, cela permet au titulaire du contrat d'abuser délibérément du contrat à son profit.
Exemple : Le prochain match de boxe à venir est Soda Popinski contre Glass Joe. Soda est le favori clair par une large marge. Tout le monde parie sur Soda. Des tonnes d'argent à cheval dessus. Moi, le titulaire du contrat, décide d'en tirer un rapide. Juste avant que le match ne soit décidé, je change l'oracle en mon propre oracle malveillant, qui est identique à l'oracle officiel sauf qu'il est codé en dur pour déclarer Glass Joe comme vainqueur. Il déclare Glass Joe, je gagne tout l'argent et personne ne peut m'arrêter. Après cela, peut-être que personne ne fera plus confiance à mon contrat, mais supposons que je m'en fiche ; peut-être que j'ai écrit et publié le contrat dans le seul but de faire ce casse.
Quelles sont les alternatives ?
1. Ne pas autoriser la modification de l'oracle
Le problème que nous avons identifié ci-dessus provient du fait que nous autorisons la modification de l'oracle par le propriétaire du contrat. Donc, supposons que nous codions en dur l'adresse oracle et que nous ne permettions pas du tout de la modifier ? Eh bien, nous pouvons réellement le faire, ce n'est pas hors de question. Mais alors la question se pose, que se passe-t-il si cet oracle s'arrête - arrête de fournir des données pour une raison quelconque ? Ensuite, nous devrons obtenir un nouvel oracle. Ou que se passe-t-il si cet oracle, initialement fiable, s'avère corrompu et n'est plus fiable ? Encore une fois, nous voudrons passer à un nouvel oracle. Si nous avons codé en dur l'oracle, alors la seule façon de changer l'oracle est de publier un nouveau contrat qui utilise un oracle différent. Ok, encore une fois, nous pouvons le faire. Ce n'est pas hors de question. Notez, bien sûr, que les contrats intelligents ne peuvent pas être facilement mis à jour aussi facilement que, par exemple, un site Web. Ne serait-ce pas facile ? Si vous remarquez un bogue ou une faille de sécurité, il vous suffit de le corriger et personne n'est plus avisé. Le modèle de déploiement de contrat intelligent est un peu plus proche du modèle logiciel rétractable ; une fois que le logiciel est entre les mains de l'utilisateur, il est là et vous ne pouvez pas le réparer. Vous devez inviter l'utilisateur à se mettre à niveau manuellement. Les contrats intelligents sont un peu similaires. Une fois que ce contrat est sur la blockchain, il est immuable comme avec le reste de la blockchain, sauf dans les parties où vous avez écrit une logique pour le rendre modifiable.
Ce n'est pas nécessairement un bloqueur cependant; il existe maintenant de nombreux modèles et écoles de pensée sur la façon de rendre modifiable un contrat intelligent. Ce sujet ferait un article décent en soi, mais pour l'instant, vous pouvez consulter cet article Hackernoon, ainsi que cet article sur les stratégies de contrats intelligents.
À quoi cela ressemblerait-il du point de vue de l'utilisateur ? Disons que j'envisage de parier sur le prochain match de Don Flamenco. Je peux clairement voir que le contrat code en dur sans complication un oracle que je connais déjà et auquel je fais confiance (enfin, assez confiance pour placer un pari d'une certaine taille). Donc c'est tout. Assez simple. Si le propriétaire du contrat publie une nouvelle version du contrat avec un nouvel oracle, je (devrais) avoir encore la liberté de continuer à utiliser l'ancien. Eh bien, peut-être. Cela dépend de la façon dont la mise à niveau a été gérée. Si le contrat était désactivé ou détruit, je n'aurais peut-être pas de chance. Mais dans le cas de la vanille, il devrait encore tenir.
2. Verrouillez l'oracle pour la durée
Nous pouvons ajouter quelques complications au code (ce n'est pas vraiment souhaitable pour un exemple trop complexe, mais pour une solution réelle, nous pouvons vouloir l'avantage que cette complexité apporte) afin d'atténuer les manigances comme celle décrite ci-dessus. Je pense qu'une chose très raisonnable à faire serait d'ajouter un code qui "verrouillerait" l'oracle pendant la durée du pari. En d'autres termes, la logique du contrat pourrait garantir de manière très claire et simple que, quel que soit l'oracle présent lorsque j'ai fait le pari, il doit être le même oracle qui est utilisé pour déterminer le gagnant. Pour que même si l'oracle change entre-temps, pour les autres matchs, pour mon match, et pour mon pari, il doit rester le même tout du long. Cela va de pair avec le fait de permettre à l'utilisateur de savoir qui est l'oracle.
Prenons un exemple rapide pour illustrer cela. Je suis un utilisateur. J'envisage de parier sur le prochain combat de Little Mac. Il y a une facilité dans le contrat qui me permet d'inspecter l'oracle qui sera utilisé pour déterminer le vainqueur de ce match. Je vérifie que le contrat est bien connu présenté par Nintendo Sports. Je me sens assez confiant dans cet oracle. (Pour ajouter un peu plus de complexité, le contrat permet peut-être aux utilisateurs de choisir parmi un éventail d'oracles disponibles pour une correspondance donnée). Maintenant, je peux inspecter le code de l'oracle et voir que la logique de l'oracle garantit que ce même oracle sera utilisé pour déterminer le résultat du match. Donc, en tant que parieur, j'ai au moins cette assurance. Cela n'exclut pas le fait que mon oracle puisse être mauvais (c'est-à-dire corrompu ou non digne de confiance) mais cela m'assure au moins qu'il ne peut pas être modifié en arrière-plan.
Un risque ici serait que l'oracle soit "hors service" (arrête d'être maintenu ou mis à jour) entre le moment où je place le pari et le moment où le match est décidé. L'argent pourrait être enfermé dans le contrat et devenir irrécupérable. Pour cela, nous pourrions (peut-être) mettre une clause activée dans le temps dans le contrat, dans laquelle si un match est indécis à une certaine heure ou date (pourrait faire partie de la définition du match), il est considéré comme "mort" et tout l'argent est bloqué à l'intérieur est retourné aux parieurs.
3. Laissez l'oracle être défini par l'utilisateur
Une solution encore plus compliquée (mais peut-être plus intéressante) serait de laisser l'adresse de l'oracle "vide", dans un sens, pour permettre aux utilisateurs de spécifier leurs propres oracles, et de former leurs propres pools de paris (via le contrat) autour de ces oracles. Des groupes d'utilisateurs qui utilisent le même oracle pourraient parier ensemble en suivant la logique du contrat. Cela oblige l'utilisateur à choisir un oracle en qui il a confiance et à partager cet oracle avec d'autres utilisateurs partageant les mêmes idées. En effet, cela fragmente la communauté des paris, donc cela ne fonctionnerait que s'il y avait une large base d'utilisateurs ; sinon, il y aurait trop peu de parieurs impliqués pour vraiment rendre le pari intéressant et rentable. Si je suis la seule personne à parier avec mon oracle préféré, il n'y a pas beaucoup d'incitation là-bas ! Mais d'un autre côté, il prend la responsabilité de choisir un oracle digne de confiance auprès du propriétaire du contrat, et il peut s'en laver les mains. Si certains utilisateurs trouvent un oracle indigne de confiance, ils cesseront simplement de l'utiliser et passeront à un autre, et personne ne se fâchera contre le propriétaire du contrat. Il a simplement fourni l'arène de pari et a rendu son service honorablement.
Ajoutant à la complication de cette stratégie est le fait que nous devrions en quelque sorte laisser un lot organique d'oracles "pousser" dans la nature, et ceux qui correspondent exactement à cette solution. Nous devrions diffuser au monde l'interface exacte à laquelle les oracles potentiels doivent adhérer, et espérer qu'un nombre suffisamment décent d'entre eux surgirait pour donner réellement un choix à l'utilisateur. Peut-être que nous pourrions ensemencer le lot avec un ou deux des nôtres. Si cela ne prend pas, nous n'avons pas de DApp de pari. Mais si c'est le cas, je dois admettre que l'idée d'oracles sélectionnés par l'utilisateur et cultivés de manière biologique dans la nature est une solution intéressante et attrayante.
2. Le propriétaire/responsable de l'oracle peut être corrompu
C'est-à-dire corrompu, dans le sens de non fiable ; que le propriétaire/mainteneur/gestionnaire de l'oracle est susceptible de proclamer un résultat incorrect pour un match, afin de s'enrichir.
Exemple : Je suis le propriétaire/gestionnaire de l'oracle réel qui alimente les données de boxe sur la blockchain pour le contrat de pari à utiliser. Mon oracle n'est pas directement impliqué dans le placement ou la gestion des paris. Son travail consiste simplement à fournir des données que le contrat de pari (et peut-être un certain nombre d'autres contrats) peut utiliser. Cependant, je peux personnellement placer un pari en utilisant le contrat de pari qui à son tour utilise mon oracle ; Je suis anonyme de toute façon, donc je n'ai pas peur des représailles. Une fois que j'ai placé un pari sur un tel contrat, il y a clairement un conflit d'intérêts. Plus précisément, l'honnêteté avec laquelle je mets à jour mon oracle avec des informations vraies et exactes peut être en conflit avec mes actions de pari.
Alors disons que dans le prochain match Sandman / von Kaiser, où von Kaiser est massivement l'outsider, je vais de l'avant et place un pari massif sur von Kaiser. Lorsque von Kaiser perd comme prévu, j'utilise mon oracle pour le proclamer faussement vainqueur ! Le contrat de pari s'exécute comme il se doit (il n'y a aucun moyen de l'arrêter à ce stade), je tue le match, il n'y a aucun recours et aucun moyen de me punir, et la vie continue. Peut-être qu'après cela, les gens refusent plus d'utiliser mon oracle ; peut-être que je m'en fous.
Comment pouvons-nous empêcher cela?
Nous en sommes maintenant à une question beaucoup plus vaste et qui touche au cœur même de la soi-disant absence de confiance en ce qui concerne les oracles. L'oracle est considéré comme un tiers neutre ou même un tiers de confiance. Le problème est que l'oracle est dirigé par des humains. Encore un autre problème est que l'oracle exerce un grand contrôle sur la façon dont le contrat client exécute ses fonctions puisqu'il fournit les données sur lesquelles le contrat agit. Comment pouvons-nous jamais savoir que nous pouvons faire confiance à un oracle donné ?
Pourquoi devrions-nous faire confiance à n'importe quel oracle ?
Si l'idée même des contrats intelligents blockchain est de supprimer le besoin de faire confiance à qui que ce soit, le fait que nous devions «faire confiance» à un oracle ne va-t-il pas à l'encontre de l'absence de confiance? Eh bien, je dirais : il est temps de grandir, fils (ou fille) ! L'absence de confiance pure n'existe pas, et la blockchain ne fournit pas un environnement sans confiance. La blockchain est une couche qui facilite les interactions humaines. Les interactions humaines sont toujours le cœur ou le résultat final, et les interactions humaines ne peuvent pas être sans confiance.
Lien : Le problème d'Oracle
L'évolution de la confiance
A la nuit des temps, comment pouvais-je faire confiance à un autre être humain ? Supposons que je chasse le mammouth, et que ce type dit qu'il m'aidera à chasser le mammouth, en échange de la moitié de la viande ? Comment peut-il croire que je fournirai la moitié ? Comment puis-je avoir confiance que cela ne me frappera pas à la tête et ne prendra pas tout le mammouth, une fois la chasse terminée ?

À cette époque, la menace de violence était probablement au cœur de nombreux types de confiance socio-économique. Si j'essaie de voler la part de ce type, je suis sûr qu'il essaiera de m'attaquer, et cela comporte des risques pour moi. Même si je suis convaincu que je gagnerais dans un combat avec lui, je (en tant qu'homme des cavernes) en sais assez sur le combat pour savoir que tout peut arriver, et je pourrais facilement subir une blessure potentiellement mortelle même si je gagne techniquement. C'est toujours un risque et un investissement d'énergie. Dans ce monde, cela pourrait suffire à garder les gens honnêtes.
En général, je ne tricherai pas car ce n'est pas dans mon intérêt , globalement et en moyenne, de le faire. En d'autres termes, le résultat attendu de la tricherie est inférieur au résultat attendu de la coopération.
Si ce n'est pas le cas, ou si les acteurs perçoivent que ce n'est pas le cas, peut-être qu'un ou plusieurs choisiront simplement de ne pas participer. Par exemple, si je vois que l'autre gars est un géant de 9 pieds de haut avec des cornes et des dents de monstre, je pourrais simplement choisir de m'enfuir et de ne pas conclure de marché; le gars a l'air trop dangereux pour moi, il pourrait simplement voler ce qu'il aime en toute impunité. Si nous sommes à peu près à égalité, alors nous percevons que nous sommes dans une situation dans laquelle il n'est dans l'intérêt d'aucune des parties de tricher, il est dans notre intérêt à tous les deux de coopérer, et donc, en supposant que les deux parties sont saines d'esprit et rationnelles, les deux parties coopéreront.
Au fur et à mesure que la culture se développait, les interactions humaines se développaient également. Ils sont devenus moins violents, même si la menace implicite de la force n'a pas disparu. Les mœurs culturelles incitaient davantage les gens à coopérer et différents types de dissuasions à tricher.
Avance rapide vers une époque de civilisation primitive; Je fais un marché pour acheter 100 boisseaux de blé. C'est une sorte de contrat à terme primitif; Je paie aujourd'hui pour le grain que je recevrai quand il sera récolté le mois prochain. Je donne au gars mes pièces de monnaie en cuivre, nous nous serrons la main, partageons un verre de bière d'orge et partons jusqu'au mois prochain pour le règlement du contrat. Semble ok.
Je me suis mis à la merci de ce type; il a tout mon argent, et je n'ai encore rien. Alors, qu'est-ce qui me rend sûr qu'il respectera le contrat ? Quelques choses. Il est un homme d'affaires; il fait régulièrement des affaires avec la population locale. Il a fait affaire avec des gens que je connais, et il a toujours livré équitablement et à temps. Il a une réputation d'honnêteté. De plus, je sais qu'il a un effet dissuasif sur la tricherie. Il gagne sa vie principalement grâce au fait qu'il est connu pour être un commerçant honnête. S'il me trompait, je le ferais savoir à tout le monde, ce qui nuirait à sa bonne réputation, et donc à ses affaires. Le montant d'argent qu'il gagne en me trompant serait faible par rapport au montant futur qu'il pourrait supporter de ne pas gagner si sa clientèle devait l'abandonner. Donc je sais que ce n'est pas forcément dans son intérêt de me tromper.
C'est bien; la menace de la force ou de la violence est absente de l'image ci-dessus. Sauf pour deux choses :
- La menace de la force n'est pas totalement absente. Un autre élément dissuasif à la tricherie pourrait être la pensée de ce qu'un gars trompé fera. J'ai des armes et des amis qui me sont fidèles. Moi, en tant que parti trompé en colère, je pourrais recourir à la force. C'est ainsi que commencent les guerres de clans !
- Il peut également y avoir un système de gouvernance en place, qui évaluera les détails de l'affaire et éventuellement infligera une amende au commerçant ou le mettra en prison. Votre dissuasion standard soutenue par le gouvernement est toujours soutenue par la menace de la force, car la punition sous-jacente pour avoir refusé de payer l'amende, refusé d'aller en prison, refusé de se conformer à toutes les mesures, est finalement la force. Et cela se poursuit jusqu'à nos jours. Si je refuse de payer une amende, je peux être arrêté. Si je refuse d'être arrêté, la force sera utilisée contre moi, et je peux être emprisonné contre mon gré ou même tué (si ma résistance est assez obstinée). Là, nous voyons la menace de la force à deux pas, même pour une infraction mineure !
La confiance décentralisée aujourd'hui
Avance rapide jusqu'à nos jours. Quels sont les freins à la rupture de contrat ? Sont-ils très différents du scénario précédent ?
L'entreprise X offre une remise postale pour l'achat de ce produit. Pourquoi avez-vous confiance qu'ils y parviendront ? Identique à l'exemple précédent ; l'entreprise a peu à gagner en trichant sur une petite somme, et beaucoup à perdre en ternissant sa réputation. C'est la base de nombreux scénarios de confiance et ce depuis longtemps. Et encore une fois, comme dans l'exemple du marchand de céréales, il y a la menace de la force, même si dans ce cas, on n'en arrivera pas là. L'entreprise peut être condamnée à une amende ou punie par un recours collectif, et l'entreprise doit payer l'amende ou faire face à des peines pires. Ces châtiments sont soutenus par un gouvernement, qui est à son tour soutenu par la menace de la force, à la fois économique et militaire, bien que l'on puisse éventuellement considérer que la menace de la force économique est à son tour soutenue par la force militaire, c'est-à-dire la violence.
Systèmes traditionnels
Le modèle de contrats soutenus par l'application de la force sanctionnée par le gouvernement a bien servi l'humanité pendant des milliers d'années ? Ou l'a-t-il ? Eh bien, c'est le cas, mais c'est une progression naturelle. En l'absence de gouvernement, des groupes de personnes forment des gouvernements. Il semble presque que vous ne pouvez pas empêcher les gens de former des gouvernements ; ils vont se former.
Alors, qu'en est-il des contrats intelligents blockchain ? Comment la blockchain et le modèle de contrat intelligent garantissent-ils la fiabilité ou découragent-ils la tricherie ? Ne vous contentez pas de dire « manque de confiance », ce n'est pas une réponse ! Dans nos exemples précédents, la tricherie est d'une certaine manière découragée.
Examinons de plus près comment la blockchain remplit (ou remplace) cette fonction.
Systèmes de chaîne de blocs : Bitcoin
Pour décomposer cette grande question en questions plus petites, commençons par le bitcoin. Comment le bitcoin décourage-t-il la triche ? Je suis libre d'exécuter n'importe quel logiciel de nœud bitcoin que je veux, tant qu'il semble adhérer aux protocoles du réseau bitcoin. Personne ne me décourage d'exécuter mon propre nœud bitcoin fait maison qui fait ce qu'il veut tout en respectant les protocoles réseau ; y a-t-il un moyen de l'utiliser pour des gains illicites ?
Bien sûr, je peux publier n'importe quel type de transaction sur le réseau bitcoin pour approbation. Je peux libérer une transaction qui m'envoie tous vos bitcoins, la diffuser sur le réseau, attendre qu'elle soit ajoutée à un bloc, et wow, maintenant tous vos bitcoins m'appartiennent ? Non, à cause du cryptage.
Je n'ai pas votre clé privée, et une telle transaction doit être signée avec votre clé privée. Du coup, j'y suis bloqué par la cryptographie. Ou suis-je? Qui a dit qu'une telle transaction devait être signée ? Que se passera-t-il si je l'essaye ? Eh bien, ce qui se passera bien sûr, c'est que l'ensemble du réseau bitcoin rejettera ma transaction. Pourquoi quelqu'un l'accepterait-il ? Mis à part le fait qu'ils exécutent tous des nœuds standard, qui le rejetteront d'emblée, pourquoi m'aideraient-ils à tricher ? Cela compromettrait certainement l'intégrité du réseau bitcoin et, ce faisant, saperait leur propre crypto-richesse. Cela n'a donc aucun sens qu'ils m'aident, moi, un inconnu anonyme, à tromper un autre inconnu anonyme. Même si un acteur irrationnel accepte d'une manière ou d'une autre ma transaction invalide, la grande majorité du réseau bitcoin la rejettera, et elle n'a aucune chance. Il est de nouveau battu, cette fois par le nombre.
Et si, cependant, je suis une puissante exploitation minière ? J'ai sûrement maintenant plus de pouvoir pour régler les choses à mon avantage. Je le fais, mais cela ne me donne toujours rien de proche du pouvoir absolu. Même en tant que mineur puissant, si je contrôle moins de 50 % du réseau, je ne peux pas faire grand-chose. J'ai un certain pouvoir pour choisir l'ordre dans lequel les transactions sont ajoutées aux blocs, mais ce n'est pas le pouvoir de frapper ou de voler des pièces. Même si je contrôle plus de 50% du réseau (en supposant ici que le lecteur est au courant de l'attaque bien connue de 51% en relation avec la preuve de travail comme dans le bitcoin), mon pouvoir principal serait de doubler les dépenses. Bien qu'il s'agisse d'un pouvoir cool, il est très douteux qu'il soit dans mon intérêt de le faire, car cela compromettrait l'intégrité du bitcoin. Il semble probable que je ferais mieux d'utiliser mon contrôle pour extraire toutes les pièces, gagner ainsi plus d'argent et maintenir le fondement sur lequel repose cette richesse. Ainsi, je ne suis pas battu, mais mon impulsion à tricher est contrecarrée par une dissuasion organiquement intégrée au protocole. Et cette dissuasion est essentiellement soutenue par la force du nombre ; le consensus écrasant des participants sur le réseau bitcoin.
Contrats intelligents Blockchain et contrats Oracle
Que sont les contrats intelligents ? Supposons que j'ai déployé un contrat trompeur pour inciter les gens à m'envoyer leur argent ? Ou supposons que j'ai déployé un contrat de pari et utilisé l'une des attaques (si vous pouvez les appeler ainsi) décrites précédemment ? Je peux faire ça, ça pourrait tromper certaines personnes; Moi, en tant qu'acteur malhonnête, je pourrais tirer un petit profit d'une telle entreprise. La défense contre cela serait que chaque participant examine attentivement (comme on devrait le faire avec tout contrat) le contrat auquel il est sur le point d'être partie et les manières potentielles dont il peut être abusé. Ils doivent également tenir compte de la source - ce qu'ils savent, le cas échéant, de la partie qui publie et maintient le contrat et tous les oracles ou contrats associés. On pourrait espérer qu'un contrat malhonnête ne durerait pas longtemps avant que le réseau ne le signale de manière informelle comme malhonnête, obligeant les participants à l'éviter volontairement, le coupant. Le réseau est vaste et les nouvelles circulent rapidement.
Sauf qu'à un moment donné, vous avez encore besoin de faire confiance à un être humain. Les données du contrat de pari sont fournies par un oracle. L'oracle est maintenu par un humain. Peu importe le nombre de couches que vous ajoutez pour tenter de garder le réseau honnête, il revient toujours à un humain à un moment donné. Alors, à quel type d'oracle feriez-vous confiance, étant donné notre exemple de pari ? Je ferais confiance à un oracle qui aurait plus à perdre qu'à gagner en trichant. Exemple : imaginez qu'ESPN ou un réseau similaire étaient les sponsors de l'oracle. Vous vous attendriez, plus que quiconque, à ce qu'ils fournissent des données honnêtes, car le gain illicite d'une petite somme dans un pari de boxe serait éclipsé par la perte de réputation qui en résulterait. Dans ce cas, votre confiance est bien placée pour la même raison que nous faisons confiance à l'honnête marchand de grains. Ce type d'entente de fiducie est ancien et bien établi.
Alors, qu'avons-nous gagné dans l'utilisation des contrats intelligents ? En quoi les contrats intelligents sont-ils différents de la gouvernance ou des méthodes précédentes de maintien des contrats ?
Emballer
Juste pour faire un point, pour donner matière à réflexion et à discussion, et pour conclure mon article, je vais présenter quelques observations simples, au lieu de conclusions difficiles. Parce que pour un sujet de cette complexité, une conclusion concise ressemble à une sorte d'histoire et à une simplification excessive. Les observations que je vais mettre en avant (et n'hésitez pas à les discuter/réfuter/contredire) sont les suivantes :
- La confiance basée sur l'hypothèse que l'autre partie a plus à gagner à coopérer qu'à tricher est ancienne, fonctionne dans des situations pratiques et n'a pas disparu. Il est toujours inhérent dans certains cas au monde de la blockchain, bien qu'il soit peut-être éliminé dans de nombreux cas. Dans le cas de notre exemple d'oracle, il est toujours bien vivant.
- La confiance basée sur la menace de la force ou de la violence est également inhérente à la société humaine depuis des temps immémoriaux, mais elle est remarquablement absente de notre modèle de contrat intelligent et a été remplacée par l'application via des combinaisons intelligentes de cryptage et de consensus à grand nombre.
Je mets au défi les autres développeurs d'Ethereum de faire deux choses :
- Pensez à n'importe quelle manière, dans les systèmes de blockchains publics (tels que bitcoin ou ethereum), dans lesquels tout est imposé par la menace implicite ou explicite de la force.
- Pensez à n'importe quel système de règles majeures dans le droit des contrats ou le droit financier moderne, qui n'est pas appliqué d'une manière ou d'une autre par la menace explicite ou implicite de la force.
Quelque chose de vieux, quelque chose de nouveau
Et je pense que nous sommes arrivés ici à la principale différence, et en fait à la vraie raison pour laquelle nous disons que les systèmes de blockchain sont «révolutionnaires», par rapport aux systèmes du passé. Dans ma façon de penser, il ne s'agit pas du tout d'absence de confiance, mais plutôt d'une plate-forme de confiance plus stable et - plus particulièrement - qui ne dépend pas du tout de la menace de la force ou de la violence.
D'une part, nous avons l'assurance ancienne et éprouvée du bénéfice mutuel dans les situations où il n'y a pas d'incitation à tricher. Ce n'est pas nouveau. Ce qui est nouveau, c'est l'introduction du consensus assisté par cryptage, qui aide à décourager la triche et à garder le système honnête. Et la synthèse de ces deux éléments a produit quelque chose de vraiment remarquable, possible pour la première fois dans l'histoire de l'humanité : un système utilisable pour de grands groupes anonymes, dans lequel on ne trouve nulle part la menace explicite ou implicite de la force comme moyen de dissuasion ou de punition. . Et c'est, je crois, ce qui est vraiment incroyable. Si cet aspect est négligé, ce que nous avons est une nouvelle technologie astucieuse (qui, je l'avoue, est assez cool comme ça). Mais lorsque cet aspect est pris en compte, il est évident que nous sommes entrés dans une nouvelle ère de gouvernance.