Vítězem hry se stal Dmitrij Pichulin, známý pod přezdívkou „deemru“. , vyvinutý společností Tradisys na blockchainu Waves.
Vyhrát v , hráč musel provést úplně poslední sázku během období 60 bloků - předtím, než vsadil jiný hráč, čímž se počítadlo vynulovalo. Vítěz obdržel všechny peníze vsazené ostatními hráči.
Robot, který vytvořil, přinesl vítězství Dmitrymu . Dmitry vsadil pouze osm sázek na jednu VLNU a nakonec vyhrál (836300 XNUMX RUB). V rozhovoru Dmitry mluvil o svém robotovi a vyhlídkách na hry na blockchainu.
Řekni nám něco málo o sobě. Co děláš? Kdy jste se začal zajímat o technologii blockchain?
Jsem vývojář v oblasti informační bezpečnosti. K blockchainu jsem přišel s humbukem roku 2017, pochopil jsem technologii a zůstal jsem u technologie.
Co bylo hlavní motivací k účasti ve hře?
Především technický zájem. Chtěl jsem zjistit, jak to funguje, najít zranitelnosti, nenechat hru skončit a samozřejmě „trollovat“ ostatní hráče.
Už jste se rozhodli, jak utratíte svou výhru? Jak to budete skladovat, když se rozhodnete je ještě neutratit?
Nemohl jsem přijít na to, co dělat s výhrou. Nečekal jsem to, takže nemám žádné plány. Zatím to zůstane tak, jak je. Možná to přejde do nějakého projektu na Waves.
Proč jste se rozhodli zúčastnit se hry pomocí robota? Jak se zrodil nápad na Patrollo? Můžete nám přiblížit jeho vývoj?
Se zranitelnostmi to nevyšlo. Zvedl jsem hru na testovací síti, hrál jsem si sám se sebou, vyzkoušel jsem všechny možnosti, ale vše se ukázalo jako „pevné“, ve smlouvě nebyly žádné zranitelnosti. Bylo jasné, že takto se vyhrát nedá.
Jak jste hledali zranitelnosti? Jaké byly vaše hypotézy? Mohl byste poskytnout příklad kódu?
Existovaly dvě hypotézy. Za prvé, útok na datový typ kontroluje záznamy datových transakcí. Očekával jsem například, že špatné kódování obejde kontrolu opětovného použití ID transakce. Druhým je útok přetečení celého čísla. Usoudil jsem, že existuje způsob, jak nastavit výšku příliš vysoko nebo záporně a pokusit se skončit v minulosti.
$tx = $wk->txBroadcast( $wk->txSign( $wk->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) ));
Co jste udělali, když jste viděli, že vaše očekávání ohledně zranitelnosti nebyla splněna?
Tradisys si ve svém telegramovém chatu stěžoval, že zatímco na síti je vše v klidu, hra bude věčná, ale ve zmatku (s aktualizacemi uzlů nebo nečekanými forky) se šance na dobré boty zvyšují. Tam jsem na chatu přijal výzvu napsat dobrého bota, což se mi o pár dní později povedlo. Napsal jsem kód Patrollo v PHP na základě mého frameworku , ve kterém se snažím zachytit všechny nejlepší techniky pro práci s blockchainem.
Otestoval jsem to na testovací síti, poslal kód na github, spustil bota na hlavní síti a zapomněl jsem na to.
Moje konfigurace Patrollo musela vyřešit dva problémy: podávat sázky tak zřídka, jak je to možné, a fungovat tak spolehlivě, jak je to jen možné.
O prvním rozhodují extrémně riskantní sázky, nejlépe v úplně posledním bloku. Nakonec jsem bota stejně umístil na předposlední blok, ale s dodatečným zpožděním 29 sekund. To umožnilo provést během celé hry pouze osm sázek.
Proč zrovna 29 sekund? Jak jsi k tomuto číslu přišel?
Postupně se objevilo 29 sekund. Zpočátku nebylo žádné zdržení, ale všiml jsem si, že na předposledním bloku byly případy simultánních sázek - to znamená, že nemělo smysl sázet. Pak došlo ke zpoždění - myslím, že to bylo 17 sekund, ale ani to nepomohlo: stále existovaly simultánní sázky. Pak jsem se rozhodl více riskovat, ale rozhodně ne mít simultánní sázky. Proč 17, 29 atd.? Prostě láska k prvočíslům. 24, 25, 26, 27, 28, 30 - všechny sloučeniny. A více než 30 sekund by bylo naprosto riskantní.
Jak byl vyřešen problém se spolehlivostí?
Spolehlivost byla řešena především mechanismem výběru pracovního uzlu a v menší míře provedením převodní transakce pro sázku předem, aby sázka v datové transakci již přesně odkazovala na existující transakci na blockchainu.
Během každého kola cyklu byly všechny uzly zadané v konfiguraci dotazovány na jejich aktuální výšku, byl vybrán uzel s nejvyšší aktuální výškou a probíhala s ním další interakce. V mém chápání to mělo chránit před forky, nedostupností, cachováním a možnými chybami na uzlech. Existuje jistota, že to byl tento jednoduchý mechanismus, který vedl k vítězství.
Jaké jsou podle vás hlavní rysy a výhody blockchainových her? Jak slibné jsou veřejné blockchainy obecně a blockchain Waves konkrétně pro vývoj her?
Hlavními výhodami jsou známá, pevná a neměnná pravidla hry plus rovné podmínky pro přístup ke hře odkudkoli na světě.
Hry o peníze mimo řetězec musí zemřít.
Waves má bohatou technickou funkčnost, ale existují nuance, a to jak vlastní každému blockchainu, tak specifické. Oba se zatím příliš dobře nepromítají do stávajících vývojářských nástrojů.
Pokud byste se například pokusili reagovat na transakce v reálném čase a ne na vzdálenost 5–10 potvrzení, dozvěděli byste se o vzácných, ale vyskytujících se jevech: transakce přeskakující z bloku na blok, transakce v některých blocích chybí a v jiných se objevují. . To vše je kritické pro rychlost a spolehlivost jakékoli aplikace a musí být vyřešeno obecným způsobem, ale zatím každý vývojář dosahuje úrovně spolehlivosti, kterou vyžaduje, sám. Časem se to vše samozřejmě vyřeší, ale zatím je zde určitá, spíše vysoká, bariéra vstupu a strach ze specifik práce skutečně decentralizovaných blockchainů obecně.
Jak se hra FOMO liší od ostatních blockchainových her, které znáte? Jaké jsou jeho výhody a nevýhody?
Jsou to dlouhé hry. Zájem o takové hry roste s výší výher a výše výher roste v čase.
V ideálním případě hra nikdy neskončí. Když hra skončí, je to smutné...
Nedávno jsem byl hra . Plánujete se ho zúčastnit?
Ano, pokud budu mít čas a zájem, učiním stejné kroky: analýza zranitelnosti, hraní si sám se sebou na testovací síti, bot, open source atd.
Nakonec nám prosím řekněte o svých plánech jako vývojář.
Zajímám se o řešení nevyřešených problémů a v tématu blockchainu je mnoho nevyřešených problémů. To je opravdová výzva! A byl přijat.
Zdroj: www.habr.com