Dmitry Pichulin, bekannt unter dem Spitznamen „deemru“, wurde der Gewinner des Spiels , entwickelt von Tradisys auf der Waves-Blockchain.
Gewinnen , musste ein Spieler innerhalb eines Zeitraums von 60 Blöcken den allerletzten Einsatz tätigen – bevor ein anderer Spieler einen Einsatz machte, wodurch der Zähler auf Null zurückgesetzt wurde. Der Gewinner erhielt den gesamten Geldeinsatz der anderen Spieler.
Der von ihm geschaffene Bot brachte Dmitry den Sieg . Dmitry machte nur acht Wetten auf eine WAVES und gewann schließlich (RUB 836300). In einem Interview sprach Dmitry über seinen Bot und die Aussichten für Spiele auf der Blockchain.
Erzähl uns etwas über dich. Was machen Sie? Wann haben Sie sich für die Blockchain-Technologie interessiert?
Ich bin Entwickler im Bereich Informationssicherheit. Ich bin mit dem Hype von 2017 zur Blockchain gekommen, habe die Technologie verstanden und bin der Technologie treu geblieben.
Was war die Hauptmotivation für die Teilnahme am Spiel?
Zunächst einmal technisches Interesse. Ich wollte herausfinden, wie es funktioniert, Schwachstellen finden, das Spiel nicht enden lassen und natürlich die anderen Spieler „trollen“.
Haben Sie sich bereits entschieden, wofür Sie Ihren Gewinn ausgeben möchten? Wie werden Sie es aufbewahren, wenn Sie es noch nicht ausgeben möchten?
Ich konnte nicht herausfinden, was ich mit den Gewinnen machen sollte. Ich habe es nicht erwartet, also habe ich keine Pläne. Vorerst bleibt es so wie es ist. Vielleicht fließt es in ein Projekt auf Waves ein.
Warum haben Sie sich entschieden, mit einem Bot am Spiel teilzunehmen? Wie ist die Idee zu Patrollo entstanden? Können Sie uns mehr über seine Entwicklung erzählen?
Mit Schwachstellen hat es nicht geklappt. Ich habe das Spiel im Testnetzwerk abgeholt, mit mir selbst gespielt, alle Optionen ausprobiert, aber es stellte sich heraus, dass alles „fest verdrahtet“ war, es gab keine Schwachstellen im Vertrag. Es wurde klar, dass dieser Weg nicht zu gewinnen war.
Wie haben Sie nach Schwachstellen gesucht? Was waren Ihre Hypothesen? Könnten Sie einen Beispielcode bereitstellen?
Es gab zwei Hypothesen. Erstens ein Angriff auf Datentypprüfungen in Datentransaktionsdatensätzen. Ich habe beispielsweise erwartet, dass eine schlechte Codierung die Überprüfung der Wiederverwendung von Transaktions-IDs umgehen würde. Der zweite ist ein Integer-Overflow-Angriff. Ich dachte, es gäbe eine Möglichkeit, die Höhe zu hoch oder negativ einzustellen und zu versuchen, in der Vergangenheit zu landen.
$tx = $wk->txBroadcast( $wk->txSign( $wk->txData( [ 'heightToGetMoney' => -9223372036854775807 ] ) ) );
Was haben Sie getan, als Sie sahen, dass Ihre Erwartungen an die Verwundbarkeit nicht erfüllt wurden?
In seinem Telegramm-Chat beklagte sich Tradisys darüber, dass im Netzwerk zwar alles ruhig sei, das Spiel aber ewig dauern werde, aber in Verwirrung (mit Node-Updates oder unerwarteten Forks) die Chancen auf gute Bots steigen. Dort nahm ich im Chat die Herausforderung an, einen guten Bot zu schreiben, was mir ein paar Tage später auch gelang. Ich habe den Patrollo-Code in PHP geschrieben, basierend auf meinem Framework , in dem ich versuche, die besten Techniken für die Arbeit mit Blockchain festzuhalten.
Ich habe es im Testnetzwerk getestet, den Code auf Github gepostet, den Bot im Hauptnetzwerk gestartet und ihn vergessen.
Meine Patrollo-Konfiguration musste zwei Probleme lösen: Wetten so selten wie möglich platzieren und so zuverlässig wie möglich funktionieren.
Der erste wird durch extrem riskante Wetten entschieden, vorzugsweise im allerletzten Block. Am Ende habe ich den Bot immer noch auf dem vorletzten Block platziert, allerdings mit einer zusätzlichen Verzögerung von 29 Sekunden. Dadurch konnten während des gesamten Spiels nur acht Wetten abgeschlossen werden.
Warum genau 29 Sekunden? Wie sind Sie auf diese Zahl gekommen?
29 Sekunden erschienen nach und nach. Zuerst gab es keine Verzögerung, aber ich bemerkte, dass es im vorletzten Block Fälle von gleichzeitigen Wetten gab – das heißt, es hatte keinen Sinn zu wetten. Dann gab es eine Verzögerung – ich glaube, es waren 17 Sekunden, aber das hat auch nicht geholfen: Es gab immer noch gleichzeitige Wetten. Dann habe ich beschlossen, mehr Risiken einzugehen, aber auf keinen Fall gleichzeitig zu wetten. Warum 17, 29 usw.? Einfach eine Liebe zu Primzahlen. 24, 25, 26, 27, 28, 30 – alle Verbindungen. 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 eines Arbeitsknotens und in geringerem Maße durch die Durchführung einer Übertragungstransaktion für die Wette im Voraus verbessert, sodass die Wette in der Datumstransaktion bereits genau auf eine bestehende Transaktion in der Blockchain verweisen würde.
Während jeder Runde des Zyklus wurden alle in der Konfiguration angegebenen Knoten nach ihrer aktuellen 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 Forks, Nichtverfügbarkeit, Caching und möglichen Fehlern auf den Knoten schützen. Es besteht die Gewissheit, 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 die Waves-Blockchain im Besonderen für die Spieleentwicklung?
Die Hauptvorteile sind die bekannten, festen und unveränderlichen Spielregeln sowie gleiche Bedingungen für den Zugriff auf das Spiel von überall auf der Welt.
Off-Chain-Geldspiele müssen sterben.
Waves verfügt über umfangreiche technische Funktionen, es gibt jedoch Nuancen, die sowohl jeder Blockchain innewohnen als auch spezifisch sind. Beides spiegelt sich noch nicht sehr gut in den vorhandenen Entwicklertools wider.
Wenn Sie beispielsweise versuchen würden, auf Transaktionen in Echtzeit und nicht in einer Entfernung von 5 bis 10 Bestätigungen zu reagieren, würden Sie von seltenen, aber auftretenden Phänomenen erfahren: Transaktionen, die von Block zu Block springen, Transaktionen, die in einigen Blöcken fehlen und in anderen auftauchen . All dies ist für die Geschwindigkeit und Zuverlässigkeit jeder Anwendung von entscheidender Bedeutung und muss allgemein gelöst werden, doch im Moment erreicht jeder Entwickler das von ihm benötigte Maß an Zuverlässigkeit selbst. Mit der Zeit wird sich das alles natürlich lösen, aber im Moment gibt es eine gewisse, ziemlich hohe Eintrittsbarriere und Angst vor den Besonderheiten der Arbeit wirklich dezentralisierter Blockchains im Allgemeinen.
Wie unterscheidet sich das FOMO-Spiel von anderen Blockchain-Spielen, die Sie kennen? Was sind seine Vor- und Nachteile?
Das sind lange Spiele. Das Interesse an solchen Spielen wächst mit der Höhe der Gewinne, und die Höhe der Gewinne wächst mit der Zeit.
Im Idealfall endet das Spiel nie. Wenn das Spiel endet, ist es traurig ...
Kürzlich war ich Spiel . Planen Sie, daran teilzunehmen?
Ja, wenn ich Zeit und Interesse habe, werde ich die gleichen Schritte unternehmen: Schwachstellenanalyse, mit mir selbst in einem Testnetzwerk, Bot, Open Source usw. herumspielen.
Bitte erzählen Sie uns abschließend von Ihren Plänen als Entwickler.
Ich bin daran interessiert, ungelöste Probleme zu lösen, und es gibt viele ungelöste Probleme im Blockchain-Thema. Das ist eine echte Herausforderung! Und er wurde angenommen.
Source: habr.com