Le réseau Ethereum, largement connu dans un cercle restreint de développeurs de chaînes de blocs, s'est déjà imposé comme une plate-forme pratique et stable pour développer des contrats intelligents. Nous essayons de mettre des contrats intelligents à la disposition des utilisateurs non préparés en proposant des contrats simples mais pratiquement utiles. Nous avons récemment développé un contrat intelligent de contestation Bet Me. Le contrat est basé sur un pari (différend) entre deux adversaires. Ils renforcent l'autosatisfaction avec un taux d'argent. Le perdant perd de l'argent et le gagnant prend tout. Je vais vous en dire plus dans cet article.
Pourquoi la blockchain est-elle ici?
Pour commencer, la question qui est rarement posée aux auteurs d'articles sur la blockchain est: la blockchain est-elle nécessaire dans cette situation? Quelles tâches sont difficiles à résoudre avec un accord oral ou un contrat juridique, mais simplement avec une blockchain?
Si deux personnes se disputent verbalement, cela se traduit souvent par un nouveau procès. "Je ne le pensais pas", "Des circonstances extérieures ont influencé le résultat, sinon j'aurais eu raison", "Oui, je n'ai pas sérieusement discuté avec vous, mais vous y avez pensé" et d'autres excuses possibles font une plaidoirie orale auprès de nombreuses personnes bien connues taux assez bas. Avec des paris sérieux et une connaissance relativement éloignée, il est plus prometteur de conclure un accord écrit et d'écrire en détail l'essence du différend, les paris, les critères de décision et toutes autres conditions que les parties jugent importantes.
Cette approche présente plusieurs inconvénients.
- Le plus souvent, il est nécessaire d'attirer un avocat, voire deux, un de chaque côté, sinon vous pouvez oublier un point important, ce qui entraînera des pertes financières.
- Souvent, seules les obligations des parties sont prescrites dans le contrat, mais la responsabilité en cas de violation de ces obligations ne l'est pas. En conséquence, il s'avère trop facile pour une partie de ne pas payer, et pour l'autre, il est extrêmement difficile et coûteux de faire passer votre argent devant les tribunaux.
- Ou il se peut que les deux parties insistent sur leur innocence, et même aller en justice ne garantit pas que le gagnant obtiendra l'argent.
- Il peut s'avérer que la partie perdante n'a tout simplement pas d'argent, et même une décision de justice ne l'obligera pas à payer ses dettes, malgré toutes les obligations.
La blockchain (et le réseau Ethereum en particulier) vous permet de travailler avec de l'argent (nous appellerons de l'argent éther; ce n'est pas tout à fait correct, mais c'est pratique et reflète suffisamment l'état réel des choses, car l'éther est assez facile à échanger contre de la monnaie fiduciaire, et vice versa). Dans le même temps, dans Ethereum, vous pouvez réduire les accords à un ensemble de règles spécifiques, il est tout simplement impossible de ne pas les respecter. Ainsi, notre contrat intelligent accepte de l'argent de chaque côté et le bloque jusqu'à ce que des événements spécifiques se produisent. Un ensemble de règles de programme prédéfinies permettra au gagnant de retirer de l'argent. C'est exactement ce dont vous avez besoin.
Implémentation
Un ensemble de règles régissant un différend peut être mis en œuvre de diverses manières. Ci-dessous, nous parlerons de ce que nous avons fait pour les utilisateurs de la plateforme Smartz.
Le différend implique deux parties. Celui qui crée la copie du contrat sur le réseau Ethereum est appelé le propriétaire du contrat (propriétaire), et son adversaire est appelé l'opposant (opposant). Le propriétaire du contrat établit une déclaration textuelle qu'il considère comme vraie. L'adversaire parie que la déclaration est fausse. La décision sur l'issue du litige est prise par un arbitre indépendant (arbitre), dont la candidature est approuvée par le propriétaire et l'opposant. L'arbitre reçoit une commission sous forme de pourcentage du montant du litige.
Le travail du contrat est divisé en plusieurs étapes successives.
- Les négociations . Le propriétaire et l'opposant, même avant la création du contrat, peuvent négocier de n'importe quelle manière pratique. Après avoir décidé conjointement qui sera l'arbitre, ils envoient au candidat une invitation à juger leur différend. A réception de l'invitation, l'arbitre verra toutes les conditions et l'Etat correspondant. Plus à ce sujet ci-dessous, mais pour l'instant il est important de comprendre que le futur arbitre doit transférer ce numéro au contrat afin de montrer à quelles conditions il est prêt à juger les débatteurs. Si le propriétaire a établi un montant non nul du dépôt de garantie (ArbiterPenaltyAmount), alors, conformément aux conditions, l'arbitre doit transférer le montant indiqué du temps d'antenne au contrat, après quoi il est bloqué jusqu'à ce que l'arbitre décide des débatteurs ou jusqu'à la date limite pour le règlement du différend. Dans ce dernier cas, l'arbitre perd la possibilité de retirer le dépôt de garantie, et ce montant est réparti également entre les parties au différend.
- Initialisation . Le propriétaire du contrat crée une instance du contrat et définit ses paramètres: objet de litige; la date à laquelle l'arbitre doit se prononcer (date limite); pourcentage de commission d'arbitrage (nombre fractionnaire ≥ 0 et <100); le montant de la caution (peut être nul), que l'arbitre doit faire comme garantie qu'il s'engage à régler le litige dans le libellé existant au bon moment. Le propriétaire définit également l'adresse Ethereum de l'arbitre en qui il a confiance. Seul le propriétaire de cette adresse pourra devenir arbitre ultérieurement.
- Tarif propriétaire Après la mise, le titulaire du contrat fait un pari. Pour ce faire, il envoie toute quantité d'éther au contrat. Ce montant est le tarif, il est bloqué à l'adresse du contrat.
- Le consentement de l'arbitre . L'enchère du propriétaire fixe les conditions du litige. L'arbitre voit maintenant l'intégralité des termes de la transaction: le libellé du différend, le délai avant lequel une décision doit être prise et, surtout, il peut comprendre la quantité d'éther qu'il recevra en récompense. Si l'arbitre est satisfait de tout, il confirme sa participation et transfère en même temps la caution d'assurance.
- Recherchez un adversaire . Après le consentement de l'arbitre, la recherche de l'adversaire commence. Le propriétaire définit l’adresse de l’opposant à l’avance, s’il est prêt à discuter uniquement avec une personne spécifique, ou laisse l’adresse vide, puis le propriétaire d’une adresse sur le réseau (à l’exception de l’arbitre et du propriétaire) peut devenir l’opposant. L'opposant confirme sa participation au litige en appelant une méthode distincte du contrat, à laquelle il transmet le numéro de version actuel des données et de la diffusion - autant que le propriétaire l'a fixé. A partir de ce moment, le pari est considéré comme terminé. Maintenant, le contrat attend la décision de l'arbitre ou la date limite.
- L'issue du différend . L'arbitre peut juger le différend de trois manières.
- Reconnaissez la déclaration comme vraie. Dans ce cas, le propriétaire du contrat peut retirer la totalité du montant de l'éther, à l'exception de la commission de l'arbitre et du dépôt de garantie (s'il y en avait un): l'argent est retiré par l'arbitre, et l'opposant ne reçoit rien.
- Reconnaissez la déclaration comme fausse. Dans ce cas, l'arbitre peut retirer l'éther du montant de la commission qui lui est due et du montant du gage. L'adversaire prend le reste, mais le propriétaire ne reçoit rien.
- déclarer le litige insoluble. Par exemple, le propriétaire a créé un différend avec la déclaration «Le match de football entre les équipes A et B, prévu dimanche prochain, se terminera par un score de 2: 1 en faveur de A». Si le match est annulé, l'arbitre ne résoudra pas le différend, mais il devrait pouvoir prendre sa promesse, car le problème ne vient pas de sa faute. Dans ce cas, chacune des parties peut demander le transfert d'air à hauteur de sa propre offre de l'adresse du contrat vers son portefeuille. - Retirer des fonds . Lorsque l'arbitre a pris une décision ou que la date limite est arrivée, chacune des parties peut demander une conclusion à l'antenne. Combien d'éther à produire, le contrat lui-même calculera, en se concentrant sur les résultats du différend.
- Destruction du contrat . Le propriétaire peut envoyer une commande d'autodestruction au contrat. Cela peut être fait soit avant la conclusion de la transaction (si l'arbitre n'a pas été trouvé), soit après son achèvement (si toutes les parties ont retiré les fonds qui leur étaient dus). Une telle opportunité sera utile si, d'une manière magique, plus d'air que reçu a été reçu à l'adresse du contrat. La probabilité d'un tel événement est très faible, mais toujours à Ethereum, il est impossible de bloquer complètement le transfert de la diffusion à l'adresse d'un contrat arbitraire, et jeter de l'argent gelé est idiot.
Maintenant, expliquons pourquoi le numéro de version de l'État est nécessaire. C'est le nombre qui augmente à chaque changement des conditions significatives du différend, telles que le libellé du différend, la taille des commissions ou les amendes de l'arbitre. Lorsque quelqu'un accepte les termes du litige, il 1) voit l'état actuel des données; 2) envoie un appel à la méthode du contrat, qui enregistre l'acceptation des termes. Si entre ces deux événements l'une des parties (très probablement le propriétaire) modifie le paramètre du contrat, vous serez d'accord avec l'autre version des données. Par exemple, un candidat arbitre entre dans l'interface du contrat sur smartz.io et voit qu'on lui propose de juger un différend sur 10 Ether (aujourd'hui, il est d'environ 3000 $) pour une commission de 1% (environ 30 $). Le candidat accepte volontiers et envoie la transaction de confirmation au réseau. Le propriétaire malhonnête voit dans le pool minier la transaction brute de l'arbitre et envoie la sienne: change la rémunération de l'arbitre de 0%. Un fraudeur place le prix du gaz au-dessus de la moyenne et, selon certaines probabilités, les mineurs peuvent traiter sa transaction plus tôt. Une telle attaque est appelée attaque de front. Le numéro de version de l'État le protège. Si la transaction propriétaire-nuisible est traitée plus tôt, le numéro de version des données du contrat changera. L'arbitre dans sa transaction a envoyé le numéro de version des données de moins. Par conséquent, le contrat refusera de terminer la transaction, un retour en arrière se produira. L'arbitre examinera les nouvelles conditions et refusera de participer ou acceptera en envoyant le numéro de version actuel des données.
Lors de l'élaboration d'un contrat éther, vous devez beaucoup penser aux mauvais scénarios. Que se passera-t-il si le propriétaire du contrat décide de priver l'arbitre? Et si l'arbitre s'avérait malhonnête? Et si l'adversaire est en fait un hacker? Ou sont-ils tous trois désireux de se tromper, parce que les enjeux du différend sont suffisamment élevés? En outre, il est nécessaire de prendre en compte toute violation potentielle du cours normal du litige, lorsque la diffusion sera bloquée dans le contrat et même le propriétaire n'y aura pas accès. Par exemple, l'option de déclarer le différend insoluble est déjà apparue lors de la mise en œuvre. Pour la même raison, la séquence des étapes du différend est la suivante: taux du propriétaire -> choix de l'arbitre -> taux de l'opposant. Il peut arriver que l'adversaire n'ait pas confirmé sa participation, et le temps limite est fixé loin dans le futur. Afin de ne pas devenir un investisseur à long terme, l'arbitre peut refuser de participer, mais uniquement jusqu'à ce que l'adversaire ait fait un pari. Et il y a beaucoup de telles nuances dans le contrat. La bonne nouvelle est que cela doit être programmé une fois et utilisé. Si le différend était officialisé sous la forme d'un contrat sur papier, en cas de telles situations frontalières, de nombreuses personnes devraient examiner chaque élément à maintes reprises et convenir entre elles de la manière de l'interpréter. La blockchain vous permet de fixer les conditions, comme dans le contrat, mais d'affecter l'interprétation des conditions à la machine virtuelle et d'avoir toujours un et un seul résultat de leur exécution.
On ne peut ignorer le problème d'un arbitre intéressé. Dans notre contrat, l'arbitre prend seul la décision. Pour les situations simples, cela suffit, mais parfois le risque d'intérêt personnel de l'arbitre est inacceptable. Une solution consiste à introduire dans la logique du contrat la possibilité d'ajouter plusieurs arbitres et de prendre une décision par vote. C'est une logique assez compliquée, surtout si vous voulez la rendre universelle pour tous les litiges possibles et leurs participants. Cependant, la bonne nouvelle est que toute la logique de l'arbitrage collectif complexe peut être déplacée vers un contrat intelligent distinct. L'adresse du contrat du propriétaire du litige s'inscrira comme arbitre. Du point de vue de l'interface, un tel contrat devrait pouvoir faire appel à plusieurs modalités du contrat de contestation: consentement à juger le litige, refus de ce consentement, trois versions de la décision et une méthode de diffusion. Dans le contrat d'arbitrage, la logique de décision de la plupart des arbitres peut être utilisée, de la même manière que dans le contrat de portefeuille multisignature, également disponible sur Smartz.io en tant que constructeur.
Pour une partie des litiges, il est possible de remplacer le groupe d'arbitres par un contrat utilisant un ou plusieurs oracles. Ou trouver une autre façon, par exemple, transformer l'argument en roulette avec une solution aléatoire. Et tout cela - sans changer le code du contrat du litige et sans compliquer la logique de son travail.
Test
Je veux dire quelques mots sur les tests. Tout le monde sait que l'automatisation des tests est bonne. Beaucoup écrivent en fait des tests pour leur code. Certaines personnes utilisent l'approche TDD dans le développement - le long et bien connu développement piloté par les tests. La principale différence entre TDD et les tests simples est que les tests sont écrits plus tôt que le code. Cela vous permet de regarder le code du contrat de l'extérieur, de ressentir les problèmes possibles et de les résoudre à l'avance. De plus, le TDD, lorsqu'il est utilisé correctement, vous permet de modifier considérablement la logique de travail si vous en avez besoin soudainement. Une bonne utilisation vient avec l'expérience. TDD n'est pas une solution miracle, comme vous pourriez le penser, en lisant de nombreux documents sur ce sujet. Dans le même temps, il est inquiétant que les guides de développement dans Truffle et Node.js ne démontrent pas du tout l'utilisation de TDD pour le développement Solidity. Les développeurs novices acquièrent de mauvaises habitudes et finissent par souffrir beaucoup.
TDD implique qu'il existe de nombreux tests dans le projet. Par exemple, le code de contrat litigieux est de 325 lignes et le code de test pour ce contrat est de 2144 lignes. À un moment donné, les tests sont devenus suffisamment volumineux pour que le test de truffe prenne plus d'une minute. Le cycle de développement dans TDD implique des tests fréquents après des modifications mineures du code. Pour que le développement ne se transforme pas en tourment, j'ai dû apprendre à Truffle à exécuter seulement une partie des tests correspondant à l'expression régulière transmise.
Sous le capot, Truffle utilise le framework Mocha pour les tests. Mocha peut filtrer le lancement des tests à intervalles réguliers, mais Truffle ne peut pas passer le paramètre --grep correspondant depuis la ligne de commande hors de la boîte. Profitant du fait que la configuration de Truffle est du code JavaScript normal, j'y ai entré une analyse des arguments de la ligne de commande et la formation de paramètres pour Mocha. La configuration, que j'ai obtenue en conséquence, est disponible dans le projet GitHub. L'implémentation n'est pas trop jolie, mais elle fonctionne et fait gagner beaucoup de temps.
Résumé
Le contrat litigieux a été conçu comme très simple en termes de fonctionnalité, mais grâce à TDD et à l'analyse de vecteurs d'attaque possibles, il a évolué vers une mise en œuvre légèrement plus riche des restrictions. Les lacunes évidentes du contrat sont liées à la seule décision de l'arbitre, mais elles peuvent être éliminées sans modifier le code du contrat de litige si le système de vote de plusieurs arbitres est mis en œuvre dans un contrat intelligent distinct. L'utilisation d'oracles pour les litiges dans lesquels cela est possible est réalisée de la même manière.
Le contrat de contestation BetMe peut être testé et exécuté à l'aide d'un modèle prédéfini sur la plateforme Smartz . Cela nécessitera une extension Metamask pour le navigateur de bureau ou Trust Wallet pour les appareils mobiles. De plus, le code source du contrat lui-même est publié sur GitHub.
Il convient de reconnaître qu'aujourd'hui, l'utilisation des technologies de la chaîne de blocs se résume principalement aux crypto-monnaies et à la question des jetons pour les ICO. Les organisations autonomes décentralisées (OAD) ne sont pas encore devenues une réalité. Mais si vous imaginez comment les systèmes de contrats de litige évolueront davantage, vous pouvez imaginer une liste d'arbitres avec une notation, par exemple, basée sur le Token Curated Registry. Une fois les différends terminés, leurs participants pouvaient voter pour ou contre les arbitres avec lesquels ils avaient affaire, changeant leur position dans le classement.
D'une part, le contrat de litige BetMe est un élément autosuffisant pratiquement applicable. Mais d'un autre côté, il pourrait bien devenir l'une des briques à partir de laquelle, au fil du temps, l'écosystème des organisations décentralisées se formera.
Les liens