Dmitry Pichulin, connu sous son surnom de "deemru", est devenu le gagnant du jeu Fhloston Paradise développé par Tradisys sur la blockchain Waves.
Pour gagner la partie , le joueur devait faire le pari le plus récent sur une période de 60 blocs - avant que le pari ne soit fait par un autre joueur, remettant ainsi le compteur à zéro. Le gagnant a obtenu tout l'argent parié par d'autres joueurs.
La victoire à Dmitry a été apportée par le bot Patrollo créé par lui. Dmitry n'a fait que huit paris sur une seule VAGUE et a donc remporté 4700 VAGUES (836300 roubles). Dans une interview, Dmitry a parlé de son bot et des perspectives de jeux de blockchain. Parlez un peu de vous. Tu fais quoi Quand vous êtes-vous intéressé à la technologie blockchain?Je suis développeur dans le domaine de la sécurité de l'information. Il est venu dans la blockchain avec un «battage médiatique» de 2017, a compris la technologie et est resté pour le bien de la technologie.
Quelle est devenue la principale motivation pour participer au jeu?Tout d'abord, un intérêt technique. Je voulais comprendre comment cela fonctionne, trouver des vulnérabilités, empêcher la fin du jeu et, bien sûr, «troll» les autres joueurs.
Avez-vous décidé comment dépenser vos gains? Que conserverez-vous si vous décidez de ne pas le dépenser encore?Je ne savais pas quoi faire de la victoire. Je ne m'y attendais pas, donc il n'y a pas de plans. Alors qu'il restera tel quel. Peut-être que cela ira 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?Avec des vulnérabilités n'a pas fonctionné. J'ai «ramassé» le jeu dans le réseau de test, joué avec moi-même, essayé toutes les options, mais tout s'est avéré «difficile», il n'y a aucune vulnérabilité dans le contrat. Il est devenu clair que l'on ne pouvait pas gagner de cette façon.
Comment avez-vous recherché les vulnérabilités? Quelles étaient vos hypothèses? Pourriez-vous donner un exemple de code?Il y avait deux hypothèses. Tout d'abord, une attaque contre les vérifications de type de données dans les enregistrements de transactions de données. Par exemple, j'espérais qu'un mauvais codage contournerait la vérification de la réutilisation des ID de transaction. La seconde est une attaque contre le débordement d'entier. J'ai pensé qu'il y avait un moyen de fixer des hauteurs trop hautes ou négatives et d'essayer d'être dans le passé.
$ tx = $ wk-> txBroadcast ($ wk-> txSign ($ wk-> txData (['heightToGetMoney' => -9223372036854775807])));
Qu'avez-vous fait lorsque vous avez vu que les attentes concernant les vulnérabilités n'étaient pas confirmées?Dans sa discussion par télégramme, Tradisys a déploré que 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 fourches imprévues), les chances de bons bots augmentent. Dans la même salle de chat, j'ai accepté le défi d'écrire un bon bot, ce que j'ai fait en quelques jours. J'ai écrit du code Patrollo en PHP, basé sur mon framework
WavesKit , dans lequel j'essaie de corriger toutes les meilleures techniques pour travailler avec la blockchain.
J'ai vérifié le travail dans le réseau de test, publié le code sur github, lancé le bot sur le réseau principal et oublié.
Ma configuration de Patrollo était censée résoudre deux problèmes: placer les paris le moins possible et travailler aussi fiable que possible.
Le premier est décidé par des paris extrêmement risqués, de préférence dans le tout dernier bloc. En conséquence, j'ai toujours mis le bot sur l'avant-dernier bloc, mais avec un retard supplémentaire de 29 secondes. Cela nous a permis de faire seulement huit paris pour l'ensemble du match.
Pourquoi exactement 29 secondes? Comment êtes-vous arrivé à ce chiffre?29 secondes sont apparues progressivement. Au début, il n'y avait pas de retard, mais j'ai remarqué qu'il y avait des cas de paris simultanés sur l'avant-dernier bloc - c'est-à-dire qu'il n'y avait aucun intérêt à parier. Puis il y a eu un retard - il semble, à 17 secondes, mais cela n'a pas aidé non plus: il y avait encore des paris simultanés. J'ai alors décidé de prendre plus de risques, mais certainement pas de parier simultanément. Pourquoi 17, 29, etc.? Juste un amour des nombres premiers. 24, 25, 26, 27, 28, 30 sont tous composites. 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é principalement déterminée par le mécanisme de sélection du nœud de travail et, dans une moindre mesure, en effectuant une transaction de transfert pour le pari à l'avance, de sorte que le pari dans la transaction de données faisait déjà précisément référence à la transaction existante dans la blockchain.
Au cours de chaque cercle du cycle, tous les nœuds spécifiés dans la configuration ont été interrogés pour leur hauteur actuelle, le nœud avec la hauteur actuelle la plus élevée a été sélectionné et une interaction supplémentaire a eu lieu avec lui. À ma connaissance, cela était censé protéger contre les fourches, l'inaccessibilité, la mise en cache et les erreurs possibles sur les nœuds. Il est certain que c'est ce mécanisme simple qui a mené à la victoire.
Quels sont, à votre avis, les principales caractéristiques et avantages des jeux blockchain? Quelle est la promesse des blockchains publiques en général et des blockchains Waves en particulier pour le développement de jeux?Les principaux avantages sont les règles du jeu bien connues, fixes et immuables, ainsi que des conditions d'accès égales au jeu depuis n'importe où dans le monde.
Les jeux pour de l'argent en dehors de la blockchain doivent mourir.
Waves possède de riches fonctionnalités techniques, mais il existe des nuances, à la fois inhérentes à toute blockchain et spécifiques. Ceux-ci et d'autres ne sont pas très bien reflétés dans les outils de développement existants.
Par exemple, si vous essayez de répondre aux transactions en temps réel, et non à une distance de 5 à 10 confirmations, vous connaissez des phénomènes rares mais qui se produisent: sauter des transactions d'un bloc à l'autre, manquer des transactions dans certains blocs et apparaître dans d'autres. Tout cela est essentiel pour la vitesse et la fiabilité de toutes les applications et devrait être décidé de manière générale, mais jusqu'à présent, chaque développeur atteint le niveau de fiabilité dont il a besoin de manière indépendante. Au fil du temps, bien sûr, tout cela sera résolu, mais jusqu'à présent, il existe un certain seuil d'entrée assez élevé et une crainte des spécificités du travail des chaînes de blocs véritablement décentralisées en général.
En quoi le jeu FOMO est-il différent des autres jeux de blockchain que vous connaissez? Quels sont ses avantages et ses inconvénients?
Ce sont des jeux à long terme. L'intérêt pour de tels jeux croît avec l'ampleur du gain, et l'ampleur du gain augmente avec le temps.
Idéal si le jeu ne se termine jamais. Quand le jeu se termine, c'est triste ...
Fhloston Paradise 2 a récemment été lancé . Envisagez-vous d'y participer?Oui, s'il y a du temps et de l'intérêt, je vais suivre les mêmes étapes: analyse des vulnérabilités, jouer avec moi-même dans un réseau de test, bot, open source, etc.
En conclusion, parlez-nous de vos projets en tant que développeur.Je suis intéressé à résoudre des problèmes non résolus, et le sujet de la blockchain a de nombreux problèmes non résolus. C'est un vrai défi! Et il est accepté.