Dmitry Pichulin, conegut amb el sobrenom de "deemru", es va convertir en el guanyador del joc , desenvolupat per Tradisys a la cadena de blocs Waves.
Per guanyar-hi , un jugador havia de fer l'última aposta durant un període de 60 blocs, abans que un altre jugador fes una aposta, restablint així el comptador a zero. El guanyador va rebre tots els diners apostats per altres jugadors.
El bot que va crear va portar la victòria a Dmitry . Dmitry només va fer vuit apostes en una ONADA i finalment va guanyar (836300 RUB). En una entrevista, Dmitry va parlar sobre el seu bot i les perspectives dels jocs a la cadena de blocs.
Parla'ns una mica de tu. Què fas? Quan et vas interessar per la tecnologia blockchain?
Sóc desenvolupador en l'àmbit de la seguretat de la informació. Vaig arribar a blockchain amb el bombo del 2017, vaig entendre la tecnologia i em vaig quedar amb la tecnologia.
Quina va ser la principal motivació per participar en el joc?
En primer lloc, l'interès tècnic. Volia esbrinar com funciona, trobar vulnerabilitats, no deixar que el joc acabés i "troller" als altres jugadors, és clar.
Ja heu decidit com gastareu els vostres guanys? Com l'emmagatzemareu si decidiu no gastar-lo encara?
No vaig saber què fer amb els guanys. No m'ho esperava, així que no tinc plans. De moment romandrà com està. Potser desembocarà en algun projecte a Waves.
Per què vas decidir participar en el joc amb un bot? Com va sorgir la idea de Patrollo? Ens pots explicar més sobre el seu desenvolupament?
No va funcionar amb vulnerabilitats. Vaig agafar el joc a la xarxa de proves, vaig jugar amb mi mateix, vaig provar totes les opcions, però tot va resultar "cablejat", no hi havia vulnerabilitats al contracte. Va quedar clar que d'aquesta manera no es podia guanyar.
Com has buscat les vulnerabilitats? Quines eren les teves hipòtesis? Podries donar un exemple de codi?
Hi havia dues hipòtesis. En primer lloc, un atac al tipus de dades comprova els registres de transaccions de dades. Per exemple, m'esperava que una codificació incorrecta obviaria la comprovació de reutilització de l'identificador de transacció. El segon és un atac de desbordament d'enter. Vaig pensar que hi havia una manera d'establir l'alçada massa alta o negativa i intentar acabar en el passat.
$tx = $wk->txBroadcast( $wk->txSign( $wk->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) ) );
Què vas fer quan vas veure que les teves expectatives de vulnerabilitat no es complien?
En el seu xat de telegrama, Tradisys es va queixar que tot i que a la xarxa tot està tranquil, el joc serà etern, però en la confusió (amb actualitzacions de nodes o bifurcacions inesperades), les possibilitats de bons bots augmenten. Allà, al xat, vaig acceptar el repte d'escriure un bon bot, que vaig fer un parell de dies després. Vaig escriure el codi de Patrollo en PHP, basat en el meu framework , en què intento captar totes les millors tècniques per treballar amb blockchain.
Ho vaig provar a la xarxa de prova, vaig publicar el codi a github, vaig llançar el bot a la xarxa principal i me'n vaig oblidar.
La meva configuració de Patrollo havia de resoldre dos problemes: fer apostes el més poques vegades possible i treballar de la manera més fiable possible.
El primer es decideix per apostes extremadament arriscades, preferiblement a l'últim bloc. Al final, encara vaig col·locar el bot al penúltim bloc, però amb un retard addicional de 29 segons. Això va permetre que només es fessin vuit apostes durant tot el joc.
Per què exactament 29 segons? Com vas arribar a aquest número?
29 segons van aparèixer gradualment. Al principi no hi va haver retard, però em vaig adonar que al penúltim bloc hi havia casos d'apostes simultànies, és a dir, no tenia sentit apostar. Llavors hi va haver un retard: crec que van ser 17 segons, però tampoc va ajudar: encara hi havia apostes simultànies. Aleshores vaig decidir córrer més riscos, però certament no fer apostes simultànies. Per què 17, 29, etc.? Només un amor pels nombres primers. 24, 25, 26, 27, 28, 30 - tots els compostos. I més de 30 segons seria completament arriscat.
Com es va resoldre el problema de la fiabilitat?
La fiabilitat es va abordar principalment pel mecanisme de selecció d'un node de treball i, en menor mesura, mitjançant la realització d'una transacció de transferència per a l'aposta per avançat, de manera que l'aposta a la transacció de data ja faria referència amb precisió a una transacció existent a la cadena de blocs.
Durant cada ronda del cicle, es van enquestar tots els nodes especificats a la configuració per a la seva alçada actual, es va seleccionar el node amb l'alçada actual més alta i es va produir una interacció posterior amb ell. Al meu entendre, se suposava que això protegeix contra les bifurcacions, la indisponibilitat, la memòria cau i els possibles errors als nodes. Hi ha confiança que va ser aquest mecanisme senzill el que va portar a la victòria.
Quines són, segons la teva opinió, les principals característiques i avantatges dels jocs blockchain? Què tan prometedores són les cadenes de blocs públiques en general i les cadenes de blocs de Waves en particular per al desenvolupament de jocs?
Els principals avantatges són les regles del joc conegudes, fixes i invariables, a més de la igualtat de condicions per accedir al joc des de qualsevol part del món.
Els jocs de diners fora de la cadena han de morir.
Waves té una rica funcionalitat tècnica, però hi ha matisos, tant inherents a qualsevol blockchain com específics. Tots dos encara no es reflecteixen molt bé a les eines de desenvolupament existents.
Per exemple, si intenteu respondre a les transaccions en temps real, i no a una distància de 5-10 confirmacions, aprendríeu sobre fenòmens rars però que es produeixen: transaccions que salten d'un bloc a un altre, transaccions que falten en alguns blocs i apareixen en altres. . Tot això és fonamental per a la rapidesa i fiabilitat de qualsevol aplicació i s'ha de resoldre de manera general, però de moment cada desenvolupador aconsegueix el nivell de fiabilitat que requereix pel seu compte. Amb el temps, òbviament, tot això es resoldrà, però ara per ara hi ha una certa barrera d'entrada, força elevada, i la por a les especificitats del treball de les blockchains realment descentralitzades en general.
En què és diferent el joc FOMO d'altres jocs blockchain que coneixeu? Quins són els seus avantatges i inconvenients?
Són jocs llargs. L'interès per aquests jocs creix amb la quantitat de guanys, i la quantitat de guanys creix amb el temps.
L'ideal és que el joc no s'acabi mai. Quan s'acaba el joc és trist...
Fa poc ho vaig ser joc . Tens pensat participar-hi?
Sí, si tinc temps i interès, faré els mateixos passos: anàlisi de vulnerabilitats, jugar amb mi mateix en una xarxa de prova, bot, codi obert, etc.
Finalment, explica'ns els teus plans com a desenvolupador.
M'interessa resoldre problemes no resolts i hi ha molts problemes no resolts en el tema de la cadena de blocs. Aquest és un autèntic repte! I va ser acceptat.
Font: www.habr.com