Дмитро Пічулін, відомий під ніком «deemru», став переможцем гри , розроблена Tradisys на блокчейні Waves.
Щоб перемогти в , гравець повинен був зробити останню ставку під час періоду з 60 блоків - до того, як ставку зробить інший гравець, обнуливши тим самим лічильник. Переможцю діставалися всі гроші, які поставили інші гравці.
Перемогу Дмитру приніс створений ним бот . Дмитро зробив лише вісім ставок по одному WAVES і у підсумку виграв (836300 XNUMX руб.). В інтерв'ю Дмитро розповів про свій бот і перспективи ігор на блокчейні.
Розкажіть трохи про себе. Чим займаєтеся? Коли зацікавилися технологією блокчейну?
Я розробник у сфері інформаційної безпеки. До блокчейну прийшов з «хайпом» 2017 року, розібрався в технології та залишився заради технології.
Що стало основною мотивацією для участі у грі?
Насамперед — технічний інтерес. Хотілося розібратися як вона працює, знайти вразливості, не дати грі закінчитися, та й «потролити» інших гравців, звичайно.
Ви вже вирішили, як витратите виграш? У чому зберігатимете його, якщо вирішите поки не витрачати?
Не придумав, що робити з виграшем. Не чекав на нього, тому й планів немає. Поки лежатиме як є. Може, в якийсь проект на Waves перейде.
Чому ви вирішили взяти участь у грі за допомогою бота? Як прийшла думка Patrollo? Чи могли б розповісти докладніше про його розробку?
З уразливістю не вийшло. Я «підняв» гру в тестовій мережі, пограв сам із собою, перепробував усі варіанти, але все виявилося «залізно», уразливостей у контракті немає. Стало ясно, що цим шляхом не перемогти.
Як ви шукали вразливості? Які були гіпотези? Чи не могли б навести приклад коду?
Гіпотез було дві. По-перше, атака на перевірки типів даних у записах дата-транзакцій. Наприклад, я розраховував, що погане кодування дозволить обійти перевірку перевикористання transaction ID. Друга — атака на ціле переповнення. Я розраховував, що є спосіб задати надто велику чи негативну висоту і спробувати опинитися у минулому.
$tx = $wk->txBroadcast( $wk->txSign( $wk->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) )));
Що ви зробили, коли побачили, що очікування на вразливості не підтвердилися?
У своєму телеграм-чаті Tradisys поскаржився, що поки в мережі все тихо, гра буде вічної, але в плутанині (при оновленнях нід або непередбачених форках) шанси у хороших ботів підвищуються. Там же, у чаті, я прийняв виклик – написати гарного бота, – що й зробив за кілька днів. Код Patrollo я написав мовою PHP на основі мого фреймворку , В якому я намагаюся зафіксувати всі найкращі техніки для роботи з блокчейном.
Перевірив роботу в тестовій мережі, виклав код на github, запустив робота в основній мережі і забув про нього.
Моя конфігурація Patrollo мала вирішувати два завдання: робити ставки якомога рідше і працювати якомога надійніше.
Перше вирішується вкрай ризикованими ставками, бажано в останньому блоці. У результаті я все ж таки поставив бота на передостанній блок, але з додатковою затримкою в 29 секунд. Це дозволило зробити лише вісім ставок за весь час гри.
Чому саме 29 секунд? Як ви прийшли до цього?
29 секунд з'явилися поступово. Спочатку затримки не було, але я помітив, що на передостанньому блоці були випадки одночасних ставок, тобто ставити не було сенсу. Тоді з'явилася затримка — здається, о 17-й секунді, але й вона не допомогла: все ще були одночасні ставки. Тоді я вирішив ризикувати сильніше, але точно, щоб не було одночасних ставок. Чому 17, 29 і т.д.? Просто любов до простих чисел. 24, 25, 26, 27, 28, 30 - всі складові. А понад 30 секунд уже було б дуже ризиковано.
Як вирішилося питання надійності?
Надійність вирішувалася, головним чином, механізмом вибору робочої ноди і меншою мірою проведенням трансфер-транзакції для ставки заздалегідь, щоб ставка в дата-транзакції вже точно посилалася на існуючу в блокчейні транзакцію.
Під час кожного кола циклу всі ноди, задані у конфігурації, опитувалися щодо їх поточної висоти, вибиралася нода з найбільшою поточної висотою, і з нею відбувалося подальше взаємодія. У моєму розумінні це мало захистити від форків, недоступності, кешування та можливих помилок на нодах. Є впевненість, що саме цей простий механізм призвів до перемоги.
У чому, на вашу думку, основні особливості та переваги ігор на блокчейні? Наскільки перспективні для розробки ігор публічні блокчейни взагалі та блокчейн Waves зокрема?
Головні переваги — відомі, зафіксовані правила гри, що не змінюються, плюс рівні умови доступу до гри з будь-якої точки світу.
Ігри на гроші поза блокчейном мають померти.
Waves має багатий технічний функціонал, проте існують нюанси, як притаманні будь-яким блокчейнам, так і специфічні. І ті, й інші поки що не дуже добре відображені у існуючих інструментах розробника.
Наприклад, якби ви спробували реагувати на транзакції в режимі реального часу, а не на дистанції в 5-10 підтверджень, ви б дізналися про рідкісні, але наявні явища: перестрибування транзакцій з блоку в блок, зникнення транзакцій в одних блоках і появи в інших. Все це критично для швидкості та надійності будь-яких додатків і має бути вирішено у загальному вигляді, але поки що кожен розробник досягає необхідного йому рівня надійності самостійно. Згодом, звичайно, все це буде вирішено, але поки що є певний, досить високий, поріг входження та страх перед специфікою роботи істинно децентралізованих блокчейнів загалом.
Чим гра FOMO відрізняється від інших відомих вам ігор на блокчейні? У чому її переваги та недоліки?
Це — ігри довгі. Інтерес до таких ігор зростає із величиною виграшу, а величина виграшу зростає з часом.
Ідеально, якщо гра ніколи не скінчиться. Коли гра закінчується – це сумно.
Нещодавно була гра . Чи плануєте взяти у ній участь?
Так, якщо буде час і інтерес, я зроблю ті самі кроки: аналіз на вразливості, гра із самим собою в тестовій мережі, бот, open source і т.д.
Насамкінець розкажіть, будь ласка, про свої плани як розробника.
Мені цікаво вирішувати невирішені завдання, а в темі блокчейна багато невирішених завдань. Це справжній виклик! І його прийнято.
Джерело: habr.com