«Non-Blockchain Games Involving Money Must Die»
Dmitry Pichulin, known under the nick «deemru», won the game Fhloston Paradise, developed by Tradisys on the Waves blockchain. Dmitry’s winning recipe was the bot Patrollo, which he created. The bot paid just eight 1 WAVES stakes for Dmitry and eventually won him 4,700 WAVES ($13,100). In this interview, Dmitry discusses his bot and prospects of blockchain games.
Could you tell us about yourself? What do you do? When did you get interested in blockchain technology?
I’m a developer in the area of information security. I came to the blockchain space with the 2017 hype, mastered the technology and stayed for the sake of technology.
What was your main motivation to play the game?
It was primarily interest in the tech part. I wanted to figure out how it works, uncover vulnerabilities, stop the game from ending and, of course, troll other players.
Why did you choose to participate with a bot? How did you arrive at the idea for Patrollo? Could you provide more details about developing it?
It didn’t work with vulnerabilities. I deployed the game on the test net, played it with myself, tried various options, but everything turned out to be rock solid. There are no vulnerabilities in the contract. So, it became clear I wasn’t going to win that way.
How did you look for vulnerabilities? What hypotheses did you have?
I had two hypotheses. First, an attack on checks of data types in DataTransaction entries. For instance, I assumed that it would be possible to bypass re-use of transaction IDs because of poor coding. The second hypothesis was an attack on integer overflow. I hoped there would be a way to set a too big or negative block height and try to get to the past.
$tx = $wk→txBroadcast ($wk→txSign ($wk→txData ([ 'heightToGetMoney' => -9223372036854775807 ])));
What did you do when you saw that your expectations regarding vulnerabilities didn«t come true?
Tradisys said on its Telegram channel that when everything is quiet in the network, the game will last forever, but in a state of uncertainty, caused by node updates or unexpected forks, good bots will have higher chances. On the spot, I accepted the challenge to write a good bot, which I did in a few days. I wrote Patrollo’s code in the PHP language, based on my framework WavesKit, in which I try to record all best technics for working with the blockchain. I ran it on the test net, uploaded the code to GitHub, released the bot to the main net and forgot about it.
My configuration of Patrollo was supposed to implement two tasks: pay stakes as seldom as possible and operate with maximum reliability.
The former was achieved thanks to paying extremely risky stakes — preferably in the very last block. Eventually, I set the bot for the second to last block, but with a 29 second delay. That allowed it to pay only eight stakes throughout the game.
Why exactly 29 seconds? How did you arrive at this figure?
I arrived at it gradually. First, there was no delay and I noticed that during the second to last block, simultaneous stakes were paid. So, paying stakes didn«t make sense. Then I added a delay — I think, it was 17 seconds, but it didn«t help: simultaneous stakes continued to be paid. So I decided to go for bigger risks to rule out simultaneous stakes. Why 17, 29 etc.? I just like prime numbers. 24, 25, 26, 27, 28, 30 are all composite numbers. And going above 30 seconds would have been too risky.
How did you resolve the reliability issue?
To a large degree, reliability was accomplished thanks to the mechanism of choosing the working node and, to a lesser degree, by sending a TransferTransaction for a stake in advance, so that the stake in the DataTransaction was definitely linked to a transaction existing on the blockchain.
During each lap of the cycle, current height of all nodes set in the configuration was measured, and the node with the largest height was chosen for further interaction. In my opinion, that worked as protection against forks, unavailability, cashing and possible node errors. I’m confident that this simple mechanism eventually led to the victory.
What are the main advantages of blockchain games? How promising are public blockchain, and, specifically, Waves, for game development?
The main advantages are known, recorded and unchanging rules of the game, as well as equal conditions for access to the game from any place in the world.
Non-blockchain games involving money must die.
Waves has a reach tech functionality, but there are some nuances — both, typical of any blockchain and specific. So far, either haven’t been reflected in the developer’s existing instruments thoroughly enough.
For instance, if you tried to react to transaction in real time rather than at a distance of five to ten confirmations, you would discover rare, but still extant instances of transactions' jumping from one block to another, disappearance and sudden reappearances in end blocks. All this is critical for speed and reliability of all applications and has to be resolved in a general way until developers achieve a necessary level of reliability by themselves. Certainly, in due course, all that will be resolved, but at this point, there is an entry barrier that’s quite high, and a fear of the specifics of truly decentralized blockchains' operation in general.
In what way is Fhloston Paradise different from other blockchain games you know?
All games like that are long-term. Interest in games of that kind grows commensurately with the size of the prize, which, in turn, increases as time elapses.
Ideally, the game wouldn’t end at all. When it ends, it is sad…
Recently, Fhloston Paradise 2 was launched. Do you plan to take part?
Yes, as long as I have time and interest, I’ll take the same steps: vulnerabilities analysis, playing with myself on the test net, creating a bot with open source etc.
And, finally, tell us about your plans as a developer.
I’m interested in resolving unresolved tasks, and in the blockchain space, there many of those. This is a true challenge. And it’s been accepted.
