Dmitry Pichulin, connu sous le surnom de « deemru », est devenu le vainqueur du jeu , développé par Tradisys sur la blockchain Waves.
Pour gagner en , un joueur devait effectuer la toute dernière mise pendant une période de 60 blocs - avant qu'un autre joueur ne fasse une mise, remettant ainsi le compteur à zéro. Le gagnant a reçu tout l’argent misé par les autres joueurs.
Le robot qu'il a créé a apporté la victoire à Dmitry . Dmitry n'a fait que huit paris sur une VAGUE et a finalement gagné (836300 XNUMX roubles). Dans une interview, Dmitry a parlé de son bot et des perspectives de jeux sur la blockchain.
Parle-nous un peu de toi. Que fais-tu? Quand avez-vous commencé à vous intéresser à la technologie blockchain ?
Je suis développeur dans le domaine de la sécurité de l'information. Je suis arrivé à la blockchain avec le battage médiatique de 2017, j'ai compris la technologie et je suis resté pour la technologie.
Quelle a été la principale motivation pour participer au jeu ?
Tout d’abord, l’intérêt technique. Je voulais comprendre comment cela fonctionne, trouver les vulnérabilités, ne pas laisser le jeu se terminer et « troller » les autres joueurs, bien sûr.
Avez-vous déjà décidé comment vous dépenserez vos gains ? Comment allez-vous le stocker si vous décidez de ne pas le dépenser encore ?
Je ne savais pas quoi faire avec les gains. Je ne m’y attendais pas, donc je n’ai aucun projet. Pour l’instant, cela restera tel quel. Peut-être que cela se retrouvera dans un projet sur Waves.
Pourquoi avez-vous décidé de participer au jeu en utilisant un bot ? Comment est née l’idée de Patrollo ? Pourriez-vous nous en dire plus sur son évolution ?
Cela n'a pas fonctionné avec les vulnérabilités. J'ai récupéré le jeu sur le réseau de test, joué avec moi-même, essayé toutes les options, mais tout s'est avéré « câblé », il n'y avait aucune vulnérabilité dans le contrat. Il est devenu clair que cette voie ne pouvait être gagnée.
Comment avez-vous recherché les vulnérabilités ? Quelles étaient vos hypothèses ? Pourriez-vous fournir un exemple de code ?
Il y avait deux hypothèses. Premièrement, une attaque contre les contrôles de type de données dans les enregistrements de transactions de données. Par exemple, je m'attendais à ce qu'un mauvais codage contourne le contrôle de réutilisation de l'ID de transaction. La seconde est une attaque par débordement d’entier. J'ai pensé qu'il y avait un moyen de régler la hauteur trop élevée ou négative et d'essayer de se retrouver dans le passé.
$tx = $sem->txBroadcast( $sem->txSign( $sem->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) ) );
Qu'avez-vous fait lorsque vous avez constaté que vos attentes en matière de vulnérabilité n'étaient pas satisfaites ?
Dans son chat par télégramme, Tradisys s'est plaint que même si tout est calme sur le réseau, le jeu sera éternel, mais dans la confusion (avec des mises à jour de nœuds ou des forks inattendus), les chances d'avoir de bons robots augmentent. Là, dans le chat, j'ai accepté le défi d'écrire un bon bot, ce que j'ai fait quelques jours plus tard. J'ai écrit le code Patrollo en PHP, basé sur mon framework , dans lequel j'essaie de capturer toutes les meilleures techniques pour travailler avec la blockchain.
Je l'ai testé sur le réseau de test, posté le code sur github, lancé le bot sur le réseau principal et je l'ai oublié.
Ma configuration Patrollo devait résoudre deux problèmes : placer des paris le plus rarement possible et fonctionner de la manière la plus fiable possible.
Le premier est décidé par des paris extrêmement risqués, de préférence dans le tout dernier bloc. Au final, j'ai quand même placé le bot sur l'avant-dernier bloc, mais avec un délai supplémentaire de 29 secondes. Cela n'a permis d'effectuer que huit paris pendant toute la partie.
Pourquoi exactement 29 secondes ? Comment êtes-vous arrivé à ce numéro ?
29 secondes sont apparues progressivement. Au début, il n'y a pas eu de retard, mais j'ai remarqué que sur l'avant-dernier bloc, il y avait des cas de paris simultanés, c'est-à-dire qu'il ne servait à rien de parier. Ensuite, il y a eu un retard - je pense que c'était 17 secondes, mais cela n'a pas aidé non plus : il y avait toujours des paris simultanés. J’ai alors décidé de prendre plus de risques, mais certainement pas de faire des paris simultanés. Pourquoi 17, 29, etc.? Juste un amour des nombres premiers. 24, 25, 26, 27, 28, 30 - tous les composés. Et plus de 30 secondes seraient complètement risquées.
Comment le problème de fiabilité a-t-il été résolu ?
La fiabilité a été assurée principalement par le mécanisme de sélection d'un nœud de travail et, dans une moindre mesure, par la réalisation d'une transaction de transfert pour le pari à l'avance, de sorte que le pari à la date de la transaction fasse déjà référence avec précision à une transaction existante sur la blockchain.
Au cours de chaque tour du cycle, tous les nœuds spécifiés dans la configuration ont été interrogés pour leur hauteur actuelle, le nœud ayant la hauteur actuelle la plus élevée a été sélectionné et une interaction supplémentaire a eu lieu avec lui. D'après ma compréhension, cela était censé protéger contre les forks, l'indisponibilité, la mise en cache et les erreurs possibles sur les nœuds. Il est certain que c'est ce mécanisme simple qui a conduit à la victoire.
Quels sont, selon vous, les principales caractéristiques et avantages des jeux blockchain ? Dans quelle mesure les blockchains publiques en général et la blockchain Waves en particulier sont-elles prometteuses pour le développement de jeux ?
Les principaux avantages sont les règles du jeu connues, fixes et immuables, ainsi que des conditions égales d'accès au jeu depuis n'importe où dans le monde.
Les jeux d’argent hors chaîne doivent mourir.
Waves possède de riches fonctionnalités techniques, mais il existe des nuances, à la fois inhérentes à toute blockchain et spécifiques. Ces deux éléments ne sont pas encore très bien reflétés dans les outils de développement existants.
Par exemple, si vous essayiez de répondre aux transactions en temps réel, et non à une distance de 5 à 10 confirmations, vous découvririez des phénomènes rares mais qui se produisent : des transactions passant d'un bloc à l'autre, des transactions manquantes dans certains blocs et apparaissant dans d'autres. . Tout cela est critique pour la rapidité et la fiabilité de toute application et doit être résolu de manière générale, mais pour l'instant, chaque développeur atteint par lui-même le niveau de fiabilité dont il a besoin. Au fil du temps, bien sûr, tout cela sera résolu, mais pour l'instant, il existe une certaine barrière à l'entrée, assez élevée, et une peur des spécificités du travail des blockchains véritablement décentralisées en général.
En quoi le jeu FOMO est-il différent des autres jeux blockchain que vous connaissez ? Quels sont ses avantages et ses inconvénients ?
Ce sont des jeux longs. L'intérêt pour ces jeux augmente avec le montant des gains, et le montant des gains augmente avec le temps.
Idéalement, le jeu ne se terminera jamais. Quand le jeu se termine, c'est triste...
Récemment, j'étais jeu . Envisagez-vous d'y participer ?
Oui, si j'ai le temps et l'intérêt, je ferai les mêmes démarches : analyse de vulnérabilité, jouer avec moi-même sur un réseau de test, bot, open source, etc.
Enfin, parlez-nous de vos projets en tant que développeur.
Je souhaite résoudre des problèmes non résolus, et il existe de nombreux problèmes non résolus dans le domaine de la blockchain. C'est un vrai défi ! Et il a été accepté.
Source: habr.com