Dmitry Pichulin, bekannt unter seinem Spitznamen "deemru", wurde der Gewinner des von Tradisys in der Waves-Blockchain entwickelten Fhloston Paradise- Spiels.
Um das Spiel zu gewinnen, musste der Spieler die letzte Wette während eines Zeitraums von 60 Blöcken abschließen - bevor die Wette von einem anderen Spieler gemacht wurde, wodurch der Zähler zurückgesetzt wurde. Der Gewinner erhielt das gesamte Geld von anderen Spielern.
Der Sieg für Dmitry wurde von dem von ihm geschaffenen Bot Patrollo gebracht. Dmitry machte nur acht Wetten auf eine WAVES und gewann infolgedessen 4700 WAVES (836300 Rubel). In einem Interview sprach Dmitry über seinen Bot und die Aussichten für Blockchain-Spiele. Erzähl ein wenig über dich. Was machen Sie? Wann haben Sie sich für Blockchain-Technologie interessiert?Ich bin Entwickler auf dem Gebiet der Informationssicherheit. Er kam mit einem „Hype“ von 2017 in die Blockchain, fand die Technologie heraus und blieb der Technologie zuliebe.
Was war die Hauptmotivation für die Teilnahme am Spiel?Zunächst ein technisches Interesse. Ich wollte herausfinden, wie es funktioniert, Schwachstellen finden, das Ende des Spiels verhindern und natürlich die anderen Spieler „trollen“.
Haben Sie sich entschieden, wie Sie Ihre Gewinne ausgeben sollen? Worin werden Sie es behalten, wenn Sie sich entscheiden, es noch nicht auszugeben?Ich habe nicht herausgefunden, was ich mit dem Sieg anfangen soll. Ich habe es nicht erwartet, also gibt es keine Pläne. Während es so liegen wird wie es ist. Vielleicht fließt es in ein Projekt auf Waves.
Warum hast du dich entschieden, mit einem Bot am Spiel teilzunehmen? Wie ist die Idee von Patrollo entstanden? Können Sie uns mehr über seine Entwicklung erzählen?Mit Schwachstellen hat nicht funktioniert. Ich habe das Spiel im Testnetzwerk „aufgegriffen“, mit mir selbst gespielt, alle Optionen ausprobiert, aber alles hat sich als „schwer“ herausgestellt, es gibt keine Schwachstellen im Vertrag. Es wurde klar, dass man so nicht gewinnen konnte.
Wie haben Sie nach Schwachstellen gesucht? Was waren Ihre Hypothesen? Könnten Sie einen Beispielcode geben?Es gab zwei Hypothesen. Zunächst prüft ein Angriff auf den Datentyp die Datentransaktionsdatensätze. Ich hatte zum Beispiel gehofft, dass eine schlechte Codierung die Prüfung auf Wiederverwendung von Transaktions-IDs umgehen würde. Der zweite ist ein Angriff auf den Ganzzahlüberlauf. Ich dachte, es gäbe eine Möglichkeit, zu hohe oder negative Höhen zu setzen und zu versuchen, in der Vergangenheit zu sein.
$ tx = $ wk-> txBroadcast ($ wk-> txSign ($ wk-> txData (['heightToGetMoney' => -9223372036854775807]));
Was haben Sie getan, als Sie sahen, dass die Erwartungen an Schwachstellen nicht bestätigt wurden?In seinem Telegramm-Chat beklagte Tradisys, dass das Spiel zwar im Netzwerk ruhig ist, das Spiel aber ewig sein wird, aber in der Verwirrung (mit Knotenaktualisierungen oder unvorhergesehenen Gabeln) steigen die Chancen auf gute Bots. Im selben Chatraum nahm ich die Herausforderung an, einen guten Bot zu schreiben, was ich in ein paar Tagen tat. Ich habe Patrollo-Code in PHP geschrieben, basierend auf meinem
WavesKit- Framework, in dem ich versuche, die besten Techniken für die Arbeit mit Blockchain zu reparieren.
Ich habe die Arbeit im Testnetzwerk überprüft, den Code auf github gepostet, den Bot im Hauptnetzwerk gestartet und vergessen.
Meine Konfiguration von Patrollo sollte zwei Probleme lösen: Wetten so wenig wie möglich platzieren und so zuverlässig wie möglich arbeiten.
Der erste wird durch extrem riskante Wetten entschieden, vorzugsweise im allerletzten Block. Infolgedessen habe ich den Bot immer noch auf den vorletzten Block gesetzt, jedoch mit einer zusätzlichen Verzögerung von 29 Sekunden. Dadurch konnten wir während der gesamten Spielzeit nur acht Wetten abschließen.
Warum genau 29 Sekunden? Wie sind Sie zu dieser Nummer gekommen?29 Sekunden erschienen allmählich. Zuerst gab es keine Verzögerung, aber ich bemerkte, dass es Fälle von gleichzeitigen Wetten auf den vorletzten Block gab - das heißt, es hatte keinen Sinn zu wetten. Dann gab es eine Verzögerung - es scheint, mit 17 Sekunden, aber es hat auch nicht geholfen: Es gab immer noch gleichzeitige Wetten. Dann habe ich mich entschlossen, Risiken stärker einzugehen, aber sicher nicht gleichzeitig zu wetten. Warum 17, 29 usw.? Nur eine Liebe zu Primzahlen. 24, 25, 26, 27, 28, 30 sind alle zusammengesetzt. Und mehr als 30 Sekunden wären völlig riskant.
Wie wurde das Zuverlässigkeitsproblem gelöst?Die Zuverlässigkeit wurde hauptsächlich durch den Mechanismus zur Auswahl des Arbeitsknotens und in geringerem Maße durch die Durchführung einer Übertragungstransaktion für die Wette im Voraus bestimmt, so dass die Wette in der Datentransaktion bereits genau auf die in der Blockchain vorhandene Transaktion Bezug nahm.
Während jedes Kreises des Zyklus wurden alle in der Konfiguration angegebenen Knoten auf ihre aktuelle Höhe abgefragt, der Knoten mit der höchsten aktuellen Höhe wurde ausgewählt und es fand eine weitere Interaktion mit ihm statt. Nach meinem Verständnis sollte dies vor Gabeln, Unzugänglichkeit, Caching und möglichen Fehlern auf Knoten schützen. Es besteht das Vertrauen, dass es dieser einfache Mechanismus war, der zum Sieg führte.
Was sind Ihrer Meinung nach die Hauptmerkmale und Vorteile von Blockchain-Spielen? Wie vielversprechend sind öffentliche Blockchains im Allgemeinen und Waves-Blockchains im Besonderen für die Spieleentwicklung?Die Hauptvorteile sind die bekannten, festen und unveränderlichen Spielregeln sowie die gleichen Bedingungen für den Zugriff auf das Spiel von überall auf der Welt.
Spiele um Geld außerhalb der Blockchain müssen sterben.
Waves verfügt über umfangreiche technische Funktionen, es gibt jedoch Nuancen, die jeder Blockchain eigen sind und spezifisch sind. Sowohl diese als auch andere spiegeln sich in den vorhandenen Entwicklertools nicht sehr gut wider.
Wenn Sie beispielsweise versucht hätten, auf Transaktionen in Echtzeit und nicht in einem Abstand von 5 bis 10 Bestätigungen zu antworten, hätten Sie seltene, aber auftretende Phänomene kennengelernt: Springen von Transaktionen von Block zu Block, Fehlen von Transaktionen in bestimmten Blöcken und Erscheinen in andere. All dies ist entscheidend für die Geschwindigkeit und Zuverlässigkeit aller Anwendungen und sollte allgemein entschieden werden. Bisher erreicht jedoch jeder Entwickler das Maß an Zuverlässigkeit, das er selbst benötigt. Mit der Zeit wird dies natürlich alles gelöst sein, aber bisher gibt es eine gewisse, ziemlich hohe Eintrittsschwelle und Angst vor den Besonderheiten der Arbeit wirklich dezentraler Blockchains im Allgemeinen.
Wie unterscheidet sich das FOMO-Spiel von anderen Blockchain-Spielen, die Sie kennen? Was sind ihre Vor- und Nachteile?
Dies sind Langzeitspiele. Das Interesse an solchen Spielen wächst mit der Größe des Gewinns und die Größe des Gewinns wächst mit der Zeit.
Ideal, wenn das Spiel nie endet. Wenn das Spiel endet, ist es traurig ...
Fhloston Paradise 2 wurde kürzlich gestartet . Planen Sie daran teilzunehmen?Ja, wenn es Zeit und Interesse gibt, werde ich die gleichen Schritte unternehmen: Analyse auf Schwachstellen, Spielen mit mir selbst in einem Testnetzwerk, Bot, Open Source usw.
Erzählen Sie uns abschließend von Ihren Plänen als Entwickler.Ich bin daran interessiert, ungelöste Probleme zu lösen, und das Blockchain-Thema hat viele ungelöste Probleme. Das ist eine echte Herausforderung! Und er wird akzeptiert.