Dmitry Pichulin, conosciuto con il soprannome di "deemru", è diventato il vincitore del gioco , sviluppato da Tradisys sulla blockchain Waves.
Per vincere , un giocatore doveva fare l'ultima scommessa durante un periodo di 60 blocchi, prima che un altro giocatore facesse una scommessa, azzerando così il contatore. Il vincitore ha ricevuto tutto il denaro scommesso dagli altri giocatori.
Il robot da lui creato ha portato la vittoria a Dmitry . Dmitry ha fatto solo otto scommesse su una WAVES e alla fine ha vinto (836300 RUB). In un'intervista, Dmitry ha parlato del suo bot e delle prospettive dei giochi sulla blockchain.
Dicci qualcosa su di te. Cosa fai? Quando hai iniziato ad interessarti alla tecnologia blockchain?
Sono uno sviluppatore nel campo della sicurezza informatica. Sono arrivato alla blockchain con l'entusiasmo del 2017, ho capito la tecnologia e sono rimasto per la tecnologia.
Qual è stata la motivazione principale per partecipare al gioco?
Innanzitutto l'interesse tecnico. Volevo capire come funziona, trovare le vulnerabilità, non lasciare che il gioco finisse e, ovviamente, "trollare" gli altri giocatori.
Hai già deciso come spenderai le tue vincite? Come lo conserverai se decidi di non spenderlo ancora?
Non riuscivo a capire cosa fare con le vincite. Non me lo aspettavo, quindi non ho programmi. Per ora rimarrà così com'è. Magari confluirà in qualche progetto su Waves.
Perché hai deciso di partecipare al gioco utilizzando un bot? Com’è nata l’idea di Patrollo? Potresti dirci di più sul suo sviluppo?
Non ha funzionato con le vulnerabilità. Ho preso il gioco sulla rete di prova, ho giocato con me stesso, ho provato tutte le opzioni, ma tutto si è rivelato “cablato”, non c'erano vulnerabilità nel contratto. È diventato chiaro che in questo modo non si poteva vincere.
Come hai cercato le vulnerabilità? Quali erano le tue ipotesi? Potresti fornire un codice di esempio?
C'erano due ipotesi. In primo luogo, un attacco ai controlli del tipo di dati nei record delle transazioni di dati. Ad esempio, mi aspettavo che una codifica errata ignorasse il controllo di riutilizzo dell'ID transazione. Il secondo è un attacco di overflow di numeri interi. Ho pensato che ci fosse un modo per impostare un'altezza troppo alta o negativa e provare a finire nel passato.
$tx = $wk->txBroadcast( $wk->txSign( $wk->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) ) );
Cosa hai fatto quando hai visto che le tue aspettative di vulnerabilità non erano state soddisfatte?
Nella sua chat su Telegram, Tradisys si è lamentato del fatto che mentre tutto è tranquillo sulla rete, il gioco sarà eterno, ma nella confusione (con aggiornamenti dei nodi o fork inaspettati) aumentano le possibilità di buoni bot. Lì, nella chat, ho accettato la sfida di scrivere un buon bot, cosa che ho fatto un paio di giorni dopo. Ho scritto il codice Patrollo in PHP, basato sul mio framework , in cui cerco di catturare tutte le migliori tecniche per lavorare con blockchain.
L'ho testato sulla rete di test, ho pubblicato il codice su github, ho lanciato il bot sulla rete principale e me ne sono dimenticato.
La mia configurazione Patrollo doveva risolvere due problemi: piazzare le scommesse il più raramente possibile e funzionare nel modo più affidabile possibile.
Il primo si decide con scommesse estremamente rischiose, preferibilmente nell'ultimo blocco. Alla fine ho comunque posizionato il bot sul penultimo blocco, ma con un ulteriore ritardo di 29 secondi. Ciò consentiva di effettuare solo otto scommesse durante l'intero gioco.
Perché esattamente 29 secondi? Come sei arrivato a questo numero?
29 secondi sono apparsi gradualmente. All'inizio non c'è stato alcun ritardo, ma ho notato che sul penultimo blocco c'erano casi di scommesse simultanee, cioè non aveva senso scommettere. Poi c'è stato un ritardo - penso che siano stati 17 secondi, ma neanche questo ha aiutato: c'erano ancora scommesse simultanee. Poi ho deciso di rischiare di più, ma sicuramente di non fare scommesse simultanee. Perché 17, 29, ecc.? Solo amore per i numeri primi. 24, 25, 26, 27, 28, 30 - tutti i composti. E più di 30 secondi sarebbero completamente rischiosi.
Come è stato risolto il problema dell'affidabilità?
L'affidabilità è stata affrontata principalmente attraverso il meccanismo di selezione di un nodo funzionante e, in misura minore, eseguendo una transazione di trasferimento per la scommessa in anticipo, in modo che la scommessa nella transazione della data facesse già riferimento accuratamente a una transazione esistente sulla blockchain.
Durante ogni ciclo del ciclo, tutti i nodi specificati nella configurazione sono stati interrogati per la loro altezza attuale, è stato selezionato il nodo con l'altezza attuale più alta e con esso ha avuto luogo un'ulteriore interazione. A mio avviso, questo avrebbe dovuto proteggere da fork, indisponibilità, memorizzazione nella cache e possibili errori sui nodi. C'è fiducia che sia stato questo semplice meccanismo a portare alla vittoria.
Quali sono, secondo te, le principali caratteristiche e vantaggi dei giochi blockchain? Quanto sono promettenti le blockchain pubbliche in generale e la blockchain Waves in particolare per lo sviluppo di giochi?
I principali vantaggi sono le regole del gioco conosciute, fisse e immutabili, oltre a pari condizioni per l'accesso al gioco da qualsiasi parte del mondo.
I giochi con soldi fuori catena devono morire.
Waves ha una ricca funzionalità tecnica, ma ci sono sfumature, sia inerenti a qualsiasi blockchain che specifiche. Entrambi non si riflettono ancora molto bene negli strumenti di sviluppo esistenti.
Ad esempio, se provassi a rispondere alle transazioni in tempo reale, e non a distanza di 5-10 conferme, verresti a conoscenza di fenomeni rari ma ricorrenti: transazioni che saltano da un blocco all'altro, transazioni che mancano in alcuni blocchi e compaiono in altri . Tutto questo è fondamentale per la velocità e l'affidabilità di qualsiasi applicazione e deve essere risolto in maniera generale, ma per ora ogni sviluppatore raggiunge da solo il livello di affidabilità di cui ha bisogno. Col tempo, ovviamente, tutto questo verrà risolto, ma per ora c'è una certa barriera all'ingresso, piuttosto alta, e la paura delle specificità del lavoro delle blockchain veramente decentralizzate in generale.
In che modo il gioco FOMO è diverso dagli altri giochi blockchain che conosci? Quali sono i suoi vantaggi e svantaggi?
Sono partite lunghe. L'interesse per tali giochi cresce con l'importo delle vincite e l'importo delle vincite cresce nel tempo.
Idealmente, il gioco non finirà mai. Quando la partita finisce è triste...
Recentemente lo sono stato gioco . Hai intenzione di prenderne parte?
Sì, se avrò tempo e interesse, farò gli stessi passi: analisi delle vulnerabilità, giocando con me stesso su una rete di test, bot, open source, ecc.
Infine, parlaci dei tuoi piani come sviluppatore.
Sono interessato a risolvere problemi irrisolti e ci sono molti problemi irrisolti nell'argomento blockchain. Questa è una vera sfida! Ed è stato accettato.
Fonte: habr.com